Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

SEP 12.1.2 - Issue with Password Protection

Created: 28 Nov 2012 | 14 comments

Hello,

I have set up SEPM 12.1.2 in our environment and everything thus far has proceeded well. I have one issue: I am trying to use the client password protection feature to keep people from disabling the client. Regular users have the option greyed out as planned, but people that are members of the local administrators group can disable without any prompts. I have it set up in the General Settings - Security Settings tab to require a password to stop the client service and to uninstall the client. Is there a setting I am missing somewhere?

Comments 14 CommentsJump to latest comment

.Brian's picture

Have a look here:

https://www.symantec.com/business/support/index?pa...

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

Berratus's picture

Brian,

Thanks for the reply. The link you posted doesn't actually do what I want. I want to try and avoid moving clients around in the console - too manual a solution.

In my first test deployment using 12.1.1, this feature worked as I wanted. "Normal" users were unable to disable the client but members of local administrators group could disable the client, provided they entered the correct password. I have set up 12.1.2 exactly the same as I did 12.1.1 but now I am not receiving a prompt.

Any other ideas I could try?

.Brian's picture

Sounds like a call to support is needed

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

LE2Strat's picture

Welcome to the club of things that worked in 12.1.1 don't work the same in 12.1.2.  I opened a support case for my issue with it disabling the Windows Firewall even when NTP isn't installed.  You might want to open a case on this as well if your configuration hasn't changed.

pete_4u2002's picture

do the clients are communicating, is the policy serial nuber same on SEPM and client?

GeoGeo's picture

Have you tried in Policies screen at the bottom expand location specific settings > Client User Interface Control Settings: Server Control click on this then clcik on Customize in the new screen that pops up.

Untick allow users to disable NTP and PTP two check boxes. This should stop the users being able to disable it.

Let me know if this works :)

Please review ideas and vote there could be something useful :)

https://www-secure.symantec.com/connect/security/ideas

 

Berratus's picture

That screen is slightly different, but I attached what I have set there.

11-28-2012 9-46-30 AM.png
Berratus's picture

Created a new case (03086619), so we'll see what Symantec has to say.

.Brian's picture

Please keep us updated. Be interested in seeing the end result.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

ragenkagen's picture

Just curious, did you upgrade clients as well or only the SEPM?  

Berratus's picture

The SEPM was a brand new build.

I used SyLinkDrop to move three clients over and once in the new server, all three upgraded to the new client.

I will try to start with a fresh install and see if that makes a difference.

Berratus's picture

Fresh install made no difference. Awaiting callback from support

Berratus's picture

OK. The only way I could get this to work somewhat how I wanted was to make the following changes:

  1. Edit the AV policy to enable and lock Auto-Protect. This greyed out the "Disable Symantec Endpoint Protect" option on the systray icon.
  2. Lock the Tamper Protection option under Clients - Policies - General Settings.
  3. Create another group without these restrictions. When someone needs to make changes, it will have to be managed by me or another domain admin level person. I would move the client into the new group and update the policies. Once done, the user will be able to do whatever they need to do. At the end of a certain time period, I would move the machine back into its original group and update the policy again.

In other words, do what Brian suggested toward the top of this thread.

Not how I wanted, but support told me that what I want isn't possible, at least with the version I am trying to use. As a refresher, I want to require a password for anyone trying to disable the client, administrator or otherwise. It seems my only options are to have it available or have it greyed out.