- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
03-23-2021 06:52 AM - edited 03-23-2021 10:56 AM
When registering IP's to Tags on panorama, do you have to specify a target or device-group or serial number in your call? How does that match/registration actually occur? Do you have to specify a "location device-group" in the call?
<uid-message><version>2.0</version><type>update</type><payload><register><entry ip="10.1.1.3"><tag><member>Test</member></tag></entry></register></payload></uid-message>
Should there be a location/device group somewhere in this statement if you are using panorama? Can you actually register dynamic address directly to panorama to distribute to the firewalls, or do you have to designate a serial and go through panorama to a firewall and not ON panorama?
Are you stuck using User-ID redistribution in order to make this work with multiple firewalls?
03-24-2021 11:34 AM - edited 03-24-2021 11:40 AM
DAG and DUG groups are a new thing.
It does not defeat the purpose as I understand why Palo Alto have done this. The user and tag mapping is a dinamic information, this why when you add this mapping with the REST-API or even manually from the GUI/CLI under the dynamic group you don't do any config commit (because it is not a static configuration as I mentioned) and because of this you can't push it from the Panorama with device groups or Templates.
You can add tag to ip/user mapping on the Panorama or special firewall and make it a redistribution point in 9.1 or 10 version and newer and the other firewalls will use their internal Authentication agents to get this information from the redistribution point (panorama or a selected firewall or even a log collector).
03-23-2021 11:52 AM
Because I am also reserching this, I found out this article https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-panorama-api/pan-os-xml-api-request-types/apply-... . I think this limitation is because the IP address or user to be part of a dynamic group is something temporary and it does not need or trigger a commit.
When you are sending the User-ID or IP to panorama you add a serial as you mention. In version 10 you can redistribute this information from Panorama to the firewalls but in earlier versions you need to send it to each firewall directly or with serial with Panorama and this is something I posted:
Also in version 9.1 this seems possible but it is not so well described:
03-24-2021 06:57 AM - edited 03-24-2021 07:18 AM
So in order to use this effectively, on older versions, you have to include a serial number of the firewall? That kind of defeats the purpose as the IP never actually get's registered to panorama then does it, it just goes directly to the firewall with the serial you specified? So with 9.1 you still have to specify a serial?
03-24-2021 11:34 AM - edited 03-24-2021 11:40 AM
DAG and DUG groups are a new thing.
It does not defeat the purpose as I understand why Palo Alto have done this. The user and tag mapping is a dinamic information, this why when you add this mapping with the REST-API or even manually from the GUI/CLI under the dynamic group you don't do any config commit (because it is not a static configuration as I mentioned) and because of this you can't push it from the Panorama with device groups or Templates.
You can add tag to ip/user mapping on the Panorama or special firewall and make it a redistribution point in 9.1 or 10 version and newer and the other firewalls will use their internal Authentication agents to get this information from the redistribution point (panorama or a selected firewall or even a log collector).
03-26-2021 02:03 PM - edited 03-26-2021 02:05 PM
Good to know. Thanks for the replies! With your info above I was able to find the tags and registrations by enabling User-ID redistribution on panorama and it automatically pushes the IP to tag registration to the firewalls. No need for serial or device group designation in the api call.
03-26-2021 03:41 PM - edited 03-26-2021 03:42 PM
Thanks. Can you mark my reply as the answer, so that the discussion can be closed?
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!