+111
Declined

uninstall password

Dustin Evans 6 years ago updated by Jstepp 2 months ago 34 2 duplicates

We would like to have the option to add a password to protect the screen connect client from being uninstalled by users with local admin privileges. I have found that when the client is installed from labtech, users don't recognize it and tend to remove it. This causes problems with the labtech SC plugin.

Available in Version:

Answer

-1
Answer
Declined

This is a feature that we will not implement for a few reasons:

  • OS settings can be applied to prevent users from uninstalling software
  • Having a password baked into the agent to prevent uninstall could be used maliciously
    • A scammer could essentially prevent an agent from being uninstalled on an unsuspecting victim of fraud
    • A legitimate agent could be left behind if the end user no longer wishes to receive service and the service provider does not uninstall the software as part of an offboarding process.

Duplicates 2

Where I understand that you want to limit the client from doing something that he should not a local administrator acces should be respected.

the level of acces screen connect give on a target computer is very important, let imagine a bad user using this feature to lock donw computer under his/her control. the way to prevent removal should be by controlling the user acces level on the target computer and not limiting a correctly authenticated local administrators form removing the software.

+2

That is normally how things would be done. However, we cannot revoke administrative access from clients that own their infrastructure. If we did that, we WOULD be using best practices but we also may not keep our clients. For most clients, limited access is transparent but for most users but for some, admin access is necessary. Furthermore, privileged operating system access for a user should not impede our ability to support that user. Usually, the user is unaware that the software was installed by us in order to support them (despite the onboarding package they receive) and they are under the impression that it is some frivolous program installed by one of those commonly used programs that installs junk along with it (not pointing any fingers) and they remove SC from their computer. When this happens, it is a big waste of time for us to fix it through LabTech. My compromise on this would be as follows; if the user tries to uninstall through the control panel, require a password but also having a command line utility that allows uninstall without a password.

+2

We just need a password prompt like trendmicro has for their software so users cannot uninstall screenconnect.

+1

Panda uses this method too. Works like a charm. Make it possible to edit the password per client, so you don't need to give them a master password, which can be used on every system.

+6

Could we, instead have the capacity to provide an custom message with logo part of the unistall screen. Then the user will know the software was install by there support compagnie with a message that would make it clear for the end user about what they are doing.

That's fair. Software installed by: <company name>

Considering for Future Release

Any movement on this?  If we do not see this on the road map soon I may be forced to move to another remote access client which is not something I am thrilled about...

Also interested in this. 

Suggested workaround - use LT to push the client to machines where it's been uninstalled. Could automate this by just dropping the correct command in the commands table. 

OR - just use LT to remove the registry entries so it's not listed in "programs" control panel. Also easy to do. 

Any movement on this yet? Also, looking for uninstall password to prevent users from uninstalling even if they have local administrator rights.

TrendMicro does this with their antivirus client.

+3

Why hasn't this been added yet? It's been a feature request for 3 years???

Clients have requested we use remote access software that includes tamper protection for the client install, I sure am going to hate using two different Remote support packages. I really hope after 5 years this is something that is actually in the works. If it is please update this post with an ETA. If not I will start looking for alternatives I guess.

As a workaround  - Ask them if they'll accept you removing its entry from Add Remove Programs so "users" don't see it as installed and try to remove it. Nuke the registry to remove the entry for it. 

+1

Wow. I am surprised this is still a request after 5 years. In my situation, there is no in-house IT personnel. A password to uninstall screenconnect is needed because while most users do not have local admin rights on their machines, there are some users who do have admin rights for whatever reasons. Having to waste time troubleshooting why you lost connection to a device, then to find out it is because the user uninstalled it is counterproductive. Even if there was in-house IT personnel, then a simple fix would allow them to know the uninstall password, if ever needed. Please can you add this request?

This will be useful feature for some corporates if you can let us choose to set this passcode when building the installer.

For corporate devices, we want to make sure certain apps are always running on devices and something like this passcode feature if it is available would be great because we normally give local admin access to some teams for development purpose and we don't want them to remove this agent without IT admin consent.

Most endpoint security agent apps has this feature of passcode to uninstall or remove agent from user devices or at least user shouldn't able to remove it unless they have some uninstaller so either of these two features is what I noticed on any endpoint manager apps.

Please review and let me know if my request makes any sense.

+1

It's discouraging this has been sitting here for 6 years. It would definitely be a nice feature. I was just encouraged in a support ticket to put in an enhancement request for this very thing. Here's my 2 cents. I have an admin user who is actually manually stopping the Screenconnect service. In the past, I've used Symantec Endpoint Protection, and Bitdefender Gravity Zone, and they both had the ability to password protect the agent such that it couldn't be uninstalled or stopped by even an admin if they didn't have the specific password to do so. I know this is not an antivirus program but IT WOULD BE AWESOME if we could have a way to protect the services from being stopped and the agent from being uninstalled. We are only dealing with corporate owned devices.

For reference:

https://techdocs.broadcom.com/us/en/symantec-security-software/endpoint-security-and-management/endpoint-protection/all/managing-groups-clients-and-administrators/managing-client-computers-v55115300-d19e131/password-protecting-the-client-v9722139-d19e3958.html

https://www.bitdefender.com/business/support/en/77209-87686-install-security-agents---use-cases.html#UUID-1258bbe7-6f50-7869-484e-67f1013b1a45

+1

Any further update on this?

+1

I realize the Feature-Request portal is where most good ideas go to die but I'll +1 this.

+1

I will plus one that this "is where most good ideas go to die". :(

Might see this feature before i leave this planet

I have been checking on this for years, could we at the very least get a reason what is stopping this from moving forward or provide measures such as a reg hack that might enable such a feature.

-1
Answer
Declined

This is a feature that we will not implement for a few reasons:

  • OS settings can be applied to prevent users from uninstalling software
  • Having a password baked into the agent to prevent uninstall could be used maliciously
    • A scammer could essentially prevent an agent from being uninstalled on an unsuspecting victim of fraud
    • A legitimate agent could be left behind if the end user no longer wishes to receive service and the service provider does not uninstall the software as part of an offboarding process.

OS settings cannot be used to prevent uninstallation by a local administrator or other suitably privileged account.   Removing the entry in add/remove programs does not prevent uninstall - it just obfuscates it so that most numpty users can't manage it. MSIEXEC /X will still work. 


If you're not implementing the password, can I suggest either an option in the installer to NOT add it to Add / Remove programs, or at the very least an official KB on how to remove it - with example commands, which would seem to address >90% of the cases here. 

I think your points about the baked in password have some validity though. 

+1

These reasons are simply silly when other solutions, as already state, offer this without issue.

Pretty sad this request has been declined without much effort. So other RMM agents like SolarWinds and Ninja have this ability. Sophos central has this ability but CWC aka ScreenConnect will not have this ability. The work arounds are not going to work for us from a management standpoint so its either switch to another remote management solution or hire a developer to build our own solution to fit our growing demands. Most of our small business environment requires most users to be the local admin of the computers due to PMP app functionality. Some users have purposely removed our management agent fearing they are being tracked but they don't grasp that our web content actually tracks them so we have had to enable remote desktop within the orgs or redeploy with gpo. 

+1

This would have been a worthwhile feature, for sure. However, since it didn't seem like it was ever going to happen, I finally found a workaround that worked "enough" for my needs. I don't want to post links here, but you can look up "sc sdset" and find documentation. Basically, you have to use the Security Templates snap-in to create a template and then you can set the permissions on any system services that you want...save the template, open the template to get the SDDL string for the service(s) and permissions...and deploy in some way to your machines. The command will look something like "sc.exe sdset LTService D:AR(D;;DCWPDTCRSD;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCLCSWLOCRRC;;;IU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)" I had to deploy with Intune, unfortunately, but I figured out a way. This was NOT something I was familiar with, so I played with it a lot before I deployed to anything, and I created a security template to UNLOCK everything and created scripts for that so that I have them when I need them.  Service lock and unlock scripts.  Maybe this will help somebody out there.  It was a huge pain, but it was the only thing that worked in my environment.