This issue is especially troublesome and it is the main reason I bought the endpoint manager and spoke to sales about it on the phone in detail. I have contacted support but am not having much luck.
I need to be able to lock the client down to where the end user can’t change their settings.
I have set the “local administration mode access” password and even created a sequence and task to push out to groups.
However this still leaves “current windows user” and “Computer administrator” as options for switching to local admin mode, which the end user is able to switch because they do have local admin rights.
I spoke to one Comodo support tech that said I shouldn’t give the end users local admin rights. While this is a great idea in a perfect world unfortunately this is not feasible within my environment. I don’t understand why when you set a “local administration mode access” password that the other options are not removed or disabled from the end user client.
I hope what I am asking for makes sense, for instance on the SEP Endpoint manager and the old Trend Micro Endpoint manager (what I am replacing), you can set a local admin password and the end user can’t do anything except scan they cannot even uninstall the product without the password. My test group will be trying to do something, say install a program and Comodo will say “no” so they simply right click the Comodo Shield and say give me permission and do as they please, a couple have even turned Comodo off altogether.
Basically, I need to keep the end user from modifying settings, turning comodo components on and off and uninstalling Comodo from the computer. Every AV I have used this has been a simple task to accomplish. Comodo did reply stating to enable the “parental controls” which I did, and this showed great promise as it was supposed to suppress the messages, but accessing the console as admin appears to bypass the parental controls and no messages are suppressed. It appears this feature does not work with the managed clients.
I feel like once a local admin password has been set that the other options should be disabled. This is probably something I am missing but I have combed through the admin guide, google searched the forums, and reached out for assistance from Comodo.
I have faced this exact issue. I have a big group of software engineers that need local admin rights on their machine to do their job. I posted several times about this issue. You should be able to create a admin password for the client and no other account should be able to make changes. I guess we will see what happens with the new version.
Thanks for writing. First let me say that we will have this feature (to disable a user with admin rights from modifying the CIS configuration) in our next release.
However, I’d have to say that the situation caused by your software vendor requiring you to give users admin rights on the PCs is the root cause – and this is something you need to work on with this vendor. I’ll give you an analogy: an employee in your building needs access to a particular room, so you’ve given him the master key, and now you’re worried that he can use it to get into the basement. This is not IT best practice, and products assume that if you have the master key, you should be able to get in. You may want to try granting AD rights to specific directories, etc. to avoid doing this – again please consult your vendor.
Thanks for feeding back.
–Glen Marianko
Product Manager
I too have a need for locking out the end user (was going to put in a feature request except TecDragon was “first in line”). Glad to hear that Comodo will be adding this feature in the hear future.
Philosophically it makes sense for the vendors to fix their apps to allow them to run in a non-privileged (non-admin) mode. But Comodo’s willingness to add this feature on short notice speaks volumes - kudos for being responsive and willing to accomodate the user base. I’ve pushed one vendor who we have this issue with to fix their application but so far it’s been a losing battle (it’s a legacy application and the CFO has no inclination to change the accounting software for the corporation).
BTW, my company is evaluating Comodo ESM / CIS and it’s refreshing to see a company that accommodates its user base as evidenced by this thread.
You have to understand… Our users write the software. In order for them to write software they need to have the ability to make drivers, make writes to memory, etc. They are writing software to be used on aircraft avionics so it’s not your typical software for PC’s. Other security product like Sophos, Symantec, and Mcafee have the same feature to make a admin login to the local client to make changes, but it is either tied into Active Directory (ex: Domain Admin or Enterprise Admin) or a client password. So even if the user is a local admin they can’t make changes to the security client.
As I have explained to Comodo engineers… You have to think outside the box. I know you guys test this software on a small lab network with less than five machines, but in the real world especially with us that are using your CESM to manage currently 75 machines (That’s just in one facility), it doesn’t work as it needs to work. I can’t tell you how much I have tried to contribute to this product becoming successful. Comodo has got to get this thing right or it will never take off.
I’ve used Comodo Personally for a while, and I’ve chucked some severe nasties at it, without a blink from IS. This is why I’ve drafted it in to replace the shockingly quiet and awful Trend Micro. After installing Endpoint IS on all the machines in one depot I hit this same problem. Although it’s great to see when a user has disabled remote management, they shouldn’t have that control over company owned machines unless we explicity give them access, and like most admins, I don’t trust the ■■■■ users put on there machines.
The same problem occurs though. I have a few users that require Admin Rights for some bespoke software, and they are power users so it’d be silly to remove this right as it only affects the few machines they use, but I want to control the AV so I know they are uniformly compliant with the rest of the network and policies I set.
What you all need to do is just elevate the “special” software, not the entire user account. If anyone is still facing this, SuRun is a free solution to this issue, though not centrally configurable. Scripts in AutoIT can elevate a specific program if you embed credentials - once compiled are difficult to extract for normal users. Also, there are a bunch of commercial products that also can elevate specific processes such as Privilige Authority…
I am agreeing with everyone else this needs to be a feature of the software. It is well understood that if the user is a local admin they can uninstall the software and even kill processes however there are plenty of ways to accomidate that.
The biggest problem are errant users who want to do things themselves. If there was a way to keep them from doing dumb things like improperly configuring the AV then the machine would be alot more secure. I have seen users disable all scans, active protection, and exclude the entire C:\ drive. This leaves the AV running but not doing anything. The AV will be fully updated and functional, just useless. This particular problem is IMPOSSIBLE to spot until there is a virus on their computer or something else.
Comodo, just give us an option to completely disable users from configuring anything!
During your EP deployment (and/or after you have your policies up and running for v2.1 and v3.0) you need simply dictate that both the CIS agent (and/or ESM agent) need to be given a password for any settings changes.
Naturally you would not use the Windows local admin passwords here as that would defeat the object
