Jump to content
carmik

KES 10: policy evaluation questions [Solved]

Recommended Posts

We have a ~ 200 system wan, composed of Windows XP (mainly) systems, Vista, 7 and some Windows 2003 servers (AD/file servers). For that purpose we are considering KES for Business:Select 10.1. Coming from an F-Secure currently installed user base, during our initial trials with KES we have run into a number of questions/issues. Any help will be vastly appreciated.

 

Now assume that I have some common settings that I want to enforce to my entire organization. However, my organization can be divided to SERVERS and CLIENTS (with different settings). Furthermore they reside in two different segments, one requiring a proxy. Therefore SERVERS is subdivided into SERVERS_LAN1 and SERVERS_LAN2. The same with clients. With F-Secure I can keep a "root" policy and then override settings of this policy on the SERVERS level, to change the things that affect only the SERVERS. And I can override again at the LAN1 and LAN2 level. Note that I am not creating any policies here, just finetuning what is provided from the top.

 

With Kaspersky it seems that I will have to create 4 policies, that have the different settings. There is a disadvantage here compared to F-secure. Let me explain:

 

If I want to change something that affects all 4 policies in F-secure, for example disable the firewall component, I would have to do only one thing, even though I have 4 groups: go to the root policy and select the firewall to be disabled. Automatically, this change would propagate to the sub-policies, since each policy at whatever level inherits from the upper level policies.

 

If I understand correctly, this can not be done with Kaspersky. The reason is that there are in reality 4 different policies, having different settings. I can not make ONE change one ONE policy and have it deployed to the subgroup policies... Is that correct?

Edited by Kravtsov Vitaly

Share this post


Link to post

Hello!

 

I think that the best way is to create separate groups and separate policies.

You can also disable the policy inheritance and try to work in that way.

 

Thank You!

Share this post


Link to post

I am not sure I understand, let me rephrase with an example. All my computers can be categorized as:

 

* Systems that should have the KES mail protection module enabled and

* Systems that should have the KES mail protection module disabled

 

Apart from this difference, ALL systems have the exact same KES configuration. Assume now that after implementation, I would like to disable the IM filter for all systems. Which would be the most clean/elegant way to do this? Can this be done by affecting a single policy?

 

So I was thinking to do the following:

* Under group "Managed Computers" create a sub-group "mail protection disabled"

* Create a policy under "Managed Computers" that contains all the common settings of all computers and also set the mail protection to be enabled

* And then what? Can I over-ride this policy in the "mail protection disabled" sub-group, to have mail protection disabled?

Edited by carmik

Share this post


Link to post
I am not sure I understand, let me rephrase with an example. All my computers can be categorized as:

 

* Systems that should have the KES mail protection module enabled and

* Systems that should have the KES mail protection module disabled

 

Apart from this difference, ALL systems have the exact same KES configuration. Assume now that after implementation, I would like to disable the IM filter for all systems. Which would be the most clean/elegant way to do this? Can this be done by affecting a single policy?

 

So I was thinking to do the following:

* Under group "Managed Computers" create a sub-group "mail protection disabled"

* Create a policy under "Managed Computers" that contains all the common settings of all computers and also set the mail protection to be enabled

* And then what? Can I over-ride this policy in the "mail protection disabled" sub-group, to have mail protection disabled?

1. Create policy for the main group and unlock the mail AV option in it

2. In the sub-group 'mail protection disabled' modify policy and disable mail AV

3. In the sub-group 'mail protection enabled' modify policy and enable mail AV

 

Please also refer to p.65 of the Administrator Guide for policy inheritance information.

Share this post


Link to post

I read page 65, but there was not much information in it. SHould the policy in the main group have "enable inheritance" enabled?

Share this post


Link to post
I read page 65, but there was not much information in it. SHould the policy in the main group have "enable inheritance" enabled?

I've attached the screenshot for you to clarify how the main group policy should be set up to make this setting manageable for sub-groups. Inheritance should be enabled.

Share this post


Link to post

This worked like a charm. It provides the same functionality with the F-secure policy manager, thank you! Consider this thread solved/closed!

Share this post


Link to post

Please set this back as "in progress". It seems like KSC does not respect the changes and loses them. I will provide a video perhaps of what goes wrong.

Share this post


Link to post

I have uploaded a small video here:

 

Basically I have my base policy under managed computers. In that base policy I have unlocked Advanced Settings -> Interface -> User support. I have two groups under managed computers, "clients" and "servers".

 

So I go to group "clients", open this policy which is inherited here, go to Advanced Settings -> Interface -> User support and enter string 'Test on "Clients"'. I press "ok" and exit the dialog. If I reopen here the same inherited policy, my changes are not there. Am I doing something wrong?

Share this post


Link to post

Lock the setting in the policy in the "client" group. Settings are not enforced on the endpoints if they are unlocked.

Share this post


Link to post

carmik,

 

You have to create a policy for your child group. Then it will inherit settins from your parent policy for all fields, except for "unlocked".

All fields that are unlocked could be changed(at that new policy) and saved.

 

What you`ve just done - you`ve tried to edit parent policy, not child.

 

PS

 

Chaos, thanks a lot.

Share this post


Link to post
Lock the setting in the policy in the "client" group. Settings are not enforced on the endpoints if they are unlocked.
Same thing. If I make a change on the child level and then lock, it also loses the lock.

 

You have to create a policy for your child group. Then it will inherit settins from your parent policy for all fields, except for "unlocked".

All fields that are unlocked could be changed(at that new policy) and saved.

 

What you`ve just done - you`ve tried to edit parent policy, not child.

Nikolay, some questions:

 

1) if I do create a policy for the child group, what will happen if later I make a change of a locked setting at the parent policy level? Will it automatically propagate to the child group level? Or should I recreate a policy for the child group?

 

2) How does checking the "Force inheritance of child policies" on the parent policy affect things, regarding locked items of the master policy?

 

3) How does checking the "Force inheritance of child policies" on the parent policy affect things, regarding unlocked items of the master policy?

 

It is still confusing, to say the least. Plus the user manual is not very well written on this part, at some point it will have to be revised for clarification. Some examples would be nice too.

Share this post


Link to post
Same thing. If I make a change on the child level and then lock, it also loses the lock.

Nikolay, some questions:

 

1) if I do create a policy for the child group, what will happen if later I make a change of a locked setting at the parent policy level? Will it automatically propagate to the child group level? Or should I recreate a policy for the child group?

 

2) How does checking the "Force inheritance of child policies" on the parent policy affect things, regarding locked items of the master policy?

 

3) How does checking the "Force inheritance of child policies" on the parent policy affect things, regarding unlocked items of the master policy?

 

It is still confusing, to say the least. Plus the user manual is not very well written on this part, at some point it will have to be revised for clarification. Some examples would be nice too.

 

Hello.

 

1) After a parent policy setting is locked, all existing child policies have the appropriate setting grayed out and the client computers receive the setting from the parent policy.

 

2) Checking "Force inheritance in child policies" enforces the option "Inherit settings from parent policy" in every child policy, disallowing you to alter their inheritance behavior. E.g. without this option checked, you can disable inheritance from parent in child policy, and change settings even if they are locked higher up. If it is checked, child policies will always inherit settings from parent. Locking and unlocking settings behaves as usual in this case.

Share this post


Link to post

Thanks Kirill. So to summarize, in order to enforce general settings for all systems, and yet be able specify different options for different subgroups, perhaps this is how should be done:

 

1) Create a parent policy with both "inherit settings from parent policy" and "force inheritance of settings in child policies"

 

2) For the options that should be the same, regardless of sub-group, modify this parent policy as appropriate and lock the relevant parts of it

 

3) For the options that are dependent on the sub-group, and might be different, modify this parent policy to have these parts unlocked

 

4) Create policies in the sub-groups as needed. Change only the parts of these subpolicies that correspond to the unlocked parts of the parent policy

 

Is this approach correct? If I follow the above-mentioned approach, will changing a setting on the parent policy propagate to affect the sub-groups as well? This is what I want, not sure if that happens.

Share this post


Link to post
Thanks Kirill. So to summarize, in order to enforce general settings for all systems, and yet be able specify different options for different subgroups, perhaps this is how should be done:

 

1) Create a parent policy with both "inherit settings from parent policy" and "force inheritance of settings in child policies"

 

2) For the options that should be the same, regardless of sub-group, modify this parent policy as appropriate and lock the relevant parts of it

 

3) For the options that are dependent on the sub-group, and might be different, modify this parent policy to have these parts unlocked

 

4) Create policies in the sub-groups as needed. Change only the parts of these subpolicies that correspond to the unlocked parts of the parent policy

 

Is this approach correct? If I follow the above-mentioned approach, will changing a setting on the parent policy propagate to affect the sub-groups as well? This is what I want, not sure if that happens.

 

Yes, this is a legitimate approach. This way, subgroup policies are obliged to inherit settings that are locked in the parent policy, but are allowed to modify ones that are unlocked in the parent policy.

If you decide to modify a setting in the parent policy that is already locked, it will apply to all subgroups. If you lock a previously unlocked setting in the parent policy, it will apply to all subgroups regardless of the previous child policy setting.

Share this post


Link to post

Thanks for the info! It is well understood now. Please turn this into a "solved' thread again.

Share this post


Link to post
Thanks for the info! It is well understood now. Please turn this into a "solved' thread again.

 

Thank you. Please let us know if you come across any other problems.

Share this post


Link to post

×
×
  • Create New...

Important Information

We use cookies to make your experience of our websites better. By using and further navigating this website you accept this. Detailed information about the use of cookies on this website is available by clicking on more information.