R80.10 versioning and Objects

[Vladimir]

Can someone enlighten me if the policy versioning preserves the configuration of the objects as well?

I.e. If the object was changed on the date after the target policy restore date, which version of the object will be utilized?

Additionally, can you tell me if cloning of the policy does anything to preserve the objects?

[Tomer_Sole]

Hi,

Can someone enlighten me if the policy versioning preserves the configuration of the objects as well?

I.e. If the object was changed on the date after the target policy restore date, which version of the object will be utilized?

The R80 architecture automatic revisions preserve the entire configuration - gateway settings, policies, objects, anything that is stored on the security management server. This means that when using Installation History to install a previous revision on the gateway, it will take the entire configuration from the mentioned date.

Now, if you are using the Layer History, then these changes only refer to rule changes - adding, removing and changing rules. Not Objects.

This is why we generally advise to use Installation History for revision management.

Please find more information here:

How do you rollback an old policy? 

can you tell me if cloning of the policy does anything to preserve the objects?

Cloning policies will only clone rules. It will not clone objects. This has been the behavior with our previous versions as well. With R80.10, if the policies contain layers which are shared, when cloning such policies, the shared layers will not be cloned but pointed at. 

Something that clones everything completely is the ExportImportPolicy tool (Python tool for exporting/importing a policy package or parts of it ) even though it may become a little hard to manage...

If one of your use cases for cloning policies is having a "last known good configuration" to install in case of problems, you may want to look at Installation History rather than cloning things. But if you have a different reason I would like to hear.

[Vladimir]

Thank you Tomer: I'm just trying to keep all the possibilities straight.

Will the situation where reversion to the previous policy where one of the objects was, for instance, a domain controller which configuration or credentials were changed since, produce any kind of warnings?

[Tomer_Sole]

You mean if the policy installation process identifies an external change that isn't part of the security management configuration? Then in that case it will not alert you. But this is an interesting point, thanks for raising it.

[Vladimir]

Not necessarily external change either.

Consider this scenario:

Admin have originally configured Identity Awareness using IA wizard.

Two weeks later, AD Domain administrative (or special account) password is changed and so were the LDAP Account Credentials in the LDAP Account Unit Properties.

Next day, some other change in the policy is causing problems.

Admin is trying to revert to the policy saved Prior to  LDAP Account Credentials alterations.

IA is going down causing even more problems.

[Tomer_Sole]

Actually in that case, installing a revision from the past will install the LDAP account unit settings of the past.

[Vladimir]

Exactly. So my question is, in this case, where revision control will impact behavior of the IA, for instance, are there any additional verification or notification mechanisms notifying administrators that this will be the case?

[Tomer_Sole]

The "view installed changes" button will show you the specific audit logs. So you will know what gets replaced. In that case, you will have to view the installed changes of the version above the one you are installing.