I think I am hitting a limitation on the template-stacks, but maybe there is a nice workaround that you guys can help me with...
Contrary to Device groups, which have "shared" objects, templates use stacks which is a little different.
The limitation to this seems to be that you can not reference a template value between different templates...
Simple example to explain what I mean:
=> if you commit; the device will receive its unique network interfaces + the shared admin user = this works and looks like template-stacking is the solution to all the "duplicate" objects between FW-templates
If we want to do something a bit more advanced (the following is just an example)
=> HERE IS THE ISSUE: you can not select the ldap-auth-profile, because the auth-profile was created in another template (the "shared-template")
So you have to be sure that all the components that will ever use a template object will have to be configred within the same template. This limitation becomes difficult fast, because a lot of the template objects are linked ex: ldap profile -> auth-profile => admin users, but also: group-mapping, globalprotect config, etc... and a lot of these things will have different config on the devices.
Anybody had similar experiences? How did you work around them?
this contradicts the nature of 'shared' 🙂
::edit:: ok i see what you did there, youre not adding the user1 in the shared, but on the firewll
pre-compilation the templates are standalone and not 'aware' of eachother, so you can't build in one template what is defined in another
A very simple and yet practical example of this limitation and a workaround is with Interface Management Profiles.
Say I have three templates (I prefix my templates with "T-")
From those three templates I build two template stacks (note that template stacks cannot have hyphens in their names, I use "TS_") and their constituent templates.
The "User" TS is assigned to the ficticious "User" firewall and the "Datacenter" TS to the fictitious "Datacenter" firewall.
Build an Interface Management Profile called "Ping-Only" in T-ACME-Baseline (which is a constituent T of both TS's). Build the Interface configuration in T-ACME-User and T-ACME-Datacenter.
From T-ACME-User and T-ACME-Datacenter this "Ping-Only" Interface Management Profile is not visible when building the Interfaces within these templates. However, from the Template Stacks themselves (TS_ACME_User and TS_ACME_Datacenter) "Ping-Only" is visible and can be applied.
When opening up an Interface from the Template Stack itself, the "Ping-Only" profile is present, but Panorama says the entire dialog box is Read Only and won't permit clicking OK. See screenshot below.
Lucky for us we can Override (note the Panorama Template selected is still the Template Stack).
After selecting Override the dialog box is no longer Read Only, "Ping-Only" profile is still visible, select it, click OK, Commit and Push.
Since the Override is within Panorama (and not a local firewall change), it will be unaffected by a "Force Template Values" push (good).
With that we are able to build a "Ping-Only" Interface Management Profile in a "Baseline" T, build our Interfaces in other T's, then apply the "Ping-Only" profile in the TS.
I have not tried the specific examples you mentioned in the post.
In summary, referencing a specific template's constructions directly in another template is not possible. However, constructions from a specific template can be combined with another specific template and actually applied using the Override function within the Template Stack.
The option to override values directly in the template stack is only available since PAN-OS 8.1. But even with this option this does not solve the example mentionned by @mr.linus. it is still not possible to reference opjects in one template which exist in another template. And back to the example with the ldap-adminuser: of course it is possible to create the ldap server and authenication profile in one base profile, but then you would have to configure the adminuser on every templatestack or at least some template stacks depending on your configuration. For other examples 8.1 solves the issue like the one with global protect: configure the server and auth profile in the base profile and then configure global protect in the template stack, like in your example. This way you can reference objects from templates that belong to thw template stack.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!