Doubts about Device-Group / Template Stack and Shared Objects:
Good afternoon, again thank you very much for the great support and collaboration that exists in this forum.
1.- To remove a Device from the Panorama administration, I imagine that references must be removed from that firewall first, before removing it, for example Remove from Device-Group and Template stack where it is configured and then proceed to Remove.
2.- Now, let's say the Template Stacks and the Device Groups that were left free and without any association with any Firewall, the procedure is to eliminate let's say from the side of the tamplate stack, remove the associated templates and then eliminate the template Stack and the tempplate and already for the Device Group it is just delete. I ask about debugging tasks, these Template and template stack and also the Device Groups, which have no reference to any firewall, can be eliminated and that's it, without problems? Or should something be checked beforehand? any additional reference? Is there any other issue in particular that needs to be checked before deleting them?
3.- I understand that when Shared type objects can be created, for example an object, these can even be referenced from the GUI example, directly from the local configuration, by locally creating a security policy and referencing that Shared object and applying it. This I clearly understand is not the best practice, but it asks, what happens if someone renames the object in Panorama , it is updated in the policies sent from Panorama, I imagine, but not from a local policy, which references the SHARED Object.
I'm a bit confused with Point 3 because of this I found:
https://docs.paloaltonetworks.com/panorama/10-1/panorama-admin/manage-firewalls/manage-device-groups/create-objects-for-use-in-shared-or-device-group-policy :
***"Shared device group objects can be viewed and referenced in a specific device group. Changing the name of a Shared device group object in one device group changes the name of the Shared object in all device groups. This includes any configuration the Shared object is referenced, such as in Policy rules.Changing the name of a Shared device group object may cause the configuration push to managed firewalls to fail.
For example, you create a Shared object named ObjectA and create a Security policy rule in the DG1 device group where ObjectA is referenced. This configuration is pushed to your managed firewalls. Later in the DG1 device group, you change the name of ObjectA to ObjectB and try to push the configuration to your managed firewalls. This push fails because your managed firewalls have the Shared object with the name ObjectA as part of their configuration, and are expecting that configuration object to have the same name."
-Here they talk about a case similar to what was raised but I don't quite understand resolution 3 that you have to USE "Merge with Device Candidate Config":
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClcICAS
- The documentation for the Merge with Device Candidate Config says the following: Merges the configuration changes pushed from Panorama with any pending configuration changes that administrators implemented locally on the target firewall. The push operation triggers PAN-OSĀ® to commit the merged changes. If you clear this selection, the commit excludes the candidate configuration on the firewall.
I thought that the Merged With Candidate Configs only referenced the pending changes without a commit made in Palo Alto locally, but reviewing Resolution 3 of LINK: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClcICAS I already have even more doubts.
Thank you very much for the support, the help and the collaboration to review these 3 points, I remain very attentive, cordial greetings.
Ok dear Reaper, thank you very much for your collaboration, support and great help, I will take very, very much into consideration point 4 that you highlight and not ask so many questions in a single post, totally agree and thank you.
Points 1 and 2 are clear to me, if I remove the firewalls from the Template Stack and from the device group, I can perfectly delete the templates (understanding that this template is not being used by any other Firewall), delete the template stack and the device group, according to your answer.
-Point 3, Point 3 of the Post, I perfectly understand the part that it is a terrible practice and should be avoided, but I still have doubts, it is still not entirely clear to me, the solution and resolution Number 3 that the link that I share below ( Merge with Device Candidate Config - https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClcICAS ) It is possible, Reaper, and appealing to your good will that you have always had with my post and your great support and collaboration, that you can briefly explain to me how Resolution 3 of the link above allows correcting the issue of changing the name of a shared object, in a local policy.
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClcICAS#:~:text=Option%203,Candidate%20Config%22%20checkbox.
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClQqCAK#:~:text=If%20the%20%22Merge,on%20running%2Dconfig.
Of course, thank you very much Reaper, and I reiterate, I totally agree with point 4, it will not be repeated in future Posts, I will no longer include so many questions in a single Post.
I remain attentive, thank you very much, greetings and attentive to your comments.
Greetings and thanks
1. Yes. First remove the shared co fog from the firewall (or load it locally) by going to device >panorama. You can remove all panorama config or import it locally, then remove the panorama IP 2. If there's unused device groups and templates, you can freely delete those 3. If you change a shared objects name, any local configuration that references the shares object now has a broken reference. Recommitting the local config (outside of panorama) should fix that but his is obviously a risk and a problem. If at all possible, don't make local policies when there is a panorama. And try not to use shared (cause, that belongs to panorama and should be created on panorama) objects if you do need local policies 4. Please don't put so many questions in one post, it makes it very hard to reply concisely and elaborately