User grouping firewall policies for all firewalls

Reply
Highlighted
L1 Bithead

User grouping firewall policies for all firewalls

Hi all,

I like to ask if it is possible, and and hot to build a scalable solution for AD grouping info to all firewalls managed by panaroma so that they can create firewall rules based on user id and grouping. 

 

Current environment I am testing:

1 panorama

1 VM firewall configured as standalone master device in a device group. It queries AD, look into syslog and connect to other userid agents(global protect internal and Prisma) to get user id information

 

Other firewalls in the environment configured userid agent pointing to the VM to learn all the userid to IP mapping info

 

How should I improve on this existing setup to further learn AD grouping info? So that I can build firewall rules using group info? Else using individual username is too much of a chore to maintain. 

 

Thankyou

 

Highlighted
Cyber Elite

@CharlesKoh,

So this varies a lot by how many firewalls are in each device group and how broad each device group actually is. So I'm going to say that we need a bit more information on how those groups are structured and how many firewalls we're actually talking about here. 

 

In general, anytime you leave the same physical network, or have to traverse a VPN, I wouldn't replicate the information using the firewalls and I would simply allow them to pull my user-id sources directly. So my VM-series firewalls that live on the same ESXi environment would all replicate to each other, but my PA-220s sitting in remote locations would simply pull AD sources themselves. 

Highlighted
L1 Bithead

@BPry 

Hi. Doing your way, does it mean the pa220 will not have the user id to IP mapping of users coming in from global protect(internal or external) since it is just querying AD? Meaning it only get the ad grouping and user-ip-mapping of those login locally?

 

I have multiple device groups to control different set of policies per group. I wish to know how to best disseminate all user information completely to all firewalls with single source of truth which is why I try make all of them point to a same single userid agent

 

 

Highlighted
Cyber Elite

@CharlesKoh,

Correct, they would learn that information through AD logs or Exchange logs. In this type of situation though the PA-220s don't need to know the source-user of anybody that isn't assigned that remote office, and if they are assigned to work from that office they would be using the GlobalProtect Gateway active on that PA-220.

 

So the question that I have for you with what you are attempting to design is this; why does ever firewall you have need to know the source-user of every single user in your environment? So a quick example of this and what I mean would be if we say that someone named Joe connects to GlobalProtect using a gateway in St.Paul. All of Joe's traffic is going to source from St.Paul and possibly go through the datacenter in Milwaukee. The only firewalls across the environment which need to care who Joe is is that firewall in St.Paul and the datacenter firewalls in Milwaukee. My other remote offices will never see traffic from Joe, the datacenter in Fort Myers will never see traffic from Joe, and they don't need to know his user information.

What I'm saying really is that when you are going through and designing user-id and replication, one of the important aspects of design isn't ensuring that every device knows the status of every single user in your environment. The firewall needs to know the user-id information for every source address for traffic which would ingress the firewall. I don't know if that means you need to replicate all user-id information to every firewall in your environment, in small environments you maybe do. In a lot of environments though you don't need, and therefore wouldn't want, to create a SOT for source user information; it just isn't really needed at scale. The local environment needs to know the source-user, depending on security/logging concerns/requirements the datacenter needs to know the source-user, but the other remote locations or offices likely don't care about their respective user information and it would be a waste to replicate all that information to them and could possibly push the platform over limits.

Highlighted
L1 Bithead

@BPry 

Thanks for the reply. I understand and agree with your point that not all firewalls need the user-id information,

Having say that, i wish to know the specifics how to disseminate info of AD grouping among firewalls, rather having them to query AD individually, can this be done?

 

large group of users are remote VPN users (prisma mobile), i get their user-id-ip-mapping via my VM firewall querying prisma as Userid agent, this same VM is querying AD for users grouping. Others local network in-office users are connected to internal gateways, and the same VM firewall is querying these gateways to get the mapping.

 

Other firewalls globally include sites server DMZs, and major datacenter firewalls already had it set to  VM firewall as userid agent to get user-id mapping info.. From the traffic log, i do able to see users are identified correctly.. Right now, what we need is to simplify firewall rules in all these regions/areas into AD grouping rules instead of IP based or specific username based.

 

I am trying to find alternative against having all these firewalls querying AD just to make configuration more standardize, example having all firewalls using same template that points to same userid agent to get user info

 

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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 Live Community as a whole!

The Live Community thanks you for your participation!