Taking you one step ahead
RADIUS controlled access to Device Groups using Panorama
We all know RADIUS, he is an old friend of us. RADIUS got its name in the old days where people actually dialled into networks. These days where dialup connections are rare we still use the term, although we do use a more creative version of the term 'dialling in'. Think about DSL users, where no actual dialing is taking place, however there still is an incoming request with user credentials and it still needs to be answered so the client can gain access. So although technology has changed, the principle is still the same.
As this blog, and all of its content intented for advanced users, I'm not going into details about RADIUS. There are many books and FAQs out there, not to mention our other good friend, Google who can assist you. The scope of this article is to show you how RADIUS can be used in Panorama to provide full device group access to customers.
As a network engineer, you may be administering a lot of Palo Alto firewalls. Which - let's face it - are a pain to administer in the first place. For this very reason, you may have been given Palo Alto's magical tool called Panorama. This is supposed to be the single point of administration. It's exactly like the Cisco Security Manager - if you can remember. That was an optional thing. This is kind of mandatory as the CLI is quite complex. For those who are fortunate enough not to be tasked with a bunch of PA firewalls, these are application-aware firewalls with CLI and GUI. Mostly the GUI is used for configuration tasks. Bundled with Panorama, the central management tool for PAs, a simple task, such as carrying out a firewall rule installation can take around 30 minutes. Yes, I know, the old access-list permit this that is history. We have zones, applications, services and commits. Commits to panorama and to the device.
Because in an enterprise environment there are many (and I mean MANY) firewalls, usually these are grouped together. If you need to imagine, picture about 8 PA firewalls around yourself, with 6-8 vsys on each. Vsys is the equivalent of contexts in Cisco environment. These are created to support different business purposes and you are given a failover pair for test and production as well.
Suppose one business unit asks for total control over their own firewalls. With the use of Panorama, this is not a trivial request to fullfill. Let's get into a detailed walkthrough, how do you do this. By the way, there is another article coming up, the same task for F5s, if you're interested.
Let's start with identifying the environment. The Panorama used here is an M-100, which provides a centralized management over HTTPS/SSL. When using panorama, you need to understand the terms. Within Panorama, you have roles, devices and templates. All vsys devices (aka. contexts) are created as if they were individual hardware firewalls. Devices can and should be grouped. In my example here today, I have them grouped according to business requirements. All firewalls belonging to a particular business unit belong to the same device group. Usually there are four devices in one group: two for production and two for testing. This is because there is always a testing environment which needs to be identical to the production, and because a firewall is usually a single point of failure, we always deploy them in pairs.
Let's start from the Panorama side. After logging in, go to the Panorama tab and go for Device Groups. This is a list of devices being grouped together. In my dummy example, here are the frontend (fe) and backend firewall groups for a single business unit.
Apologies for the black rectangles, I'm sure you can understand that I have to black out most system names as they are confidential. I'll try to make this as understandable as possible however.
As you can see, there are four device groups that we're currently interested in, each of them consists two virtual systems, each of these being on a different hardware. In this dummy example the virtual system's name refers to the business unit, I'll call it BU-vsys. The firewalls are named as iefw for internet firewall, fe for frontend, be for backend. For example the device group name
As you may already have guessed, these device groups are what the customer is interested in, and he wants full control over these. The task is to make this happen while restricting access to everything else. The next step is to combine all of the device groups into one access domain. Access domain is a term in Panorama and several device groups together are called an access domain.
As you can see in this image, the four device groups (which are distributed over different physical firewalls) are grouped together in an access-domain. I'll call this access domain BU-inet-all, the name will represent the business unit and the fact that this access domain allows access to all internet facing firewall contexts.
This step is quite important as how the Panorama works, it will expect the access domain name to be passed in an AVP. As we're all familiar with RADIUS, we all know that an AVP is an Attribute Value Pair, so no need for me to explain.
Now we have 50% of the basics. Because now we have the interesting devices grouped into several device groups, and we have these combined into one access domain, obviously, now we can tell Panorama what devices does the customer have access to. Now it's time to tell what kind of access that is.
For this, we need to go in Panorama to Admin Roles. This is on the very same page. If you have paid attention, we have used the same Panorama tab so far. Let's create a new Admin Role, this will tell Panorama what to be able to do when this attribute is passed by RADIUS. Let's name the new role as Device-Group-Full-Access so the name reflects the intention. The configuration looks like this
It's kind of straightforward what to configure here and it's a long list. I'd better list the ones that are _not_ enabled. So in your case, please set accordingly, in my case, we have the the following set to read only: Panorama/Templates, Panorama/Managed Devices, Panorama/Device Groups and the following to disable: tags Panorama/Device Deployment, globalprotect/MDM. Everything else is enabled.
Now we have all the basics. We have the list of allowed actions to perform, and the list of virtual devices on which these actions can be performed on. Time to logon to the RADIUS server. In my example I'm using a Cisco ACS but the settings are all the same no matter the software or the version. Any RADIUS will do. First, make sure you have the username and password sorted out. I'll be using a local user for testing, but this could be an AD user too.
As the image shows, I have a tmp-blogtest account which belongs to a group called (for the sake of this blog) BU AdminRWGroup. The password is all set up locally. In the ACS this group has nothing special set up, it all relies on the policies. So after creating your group, just name it something you'd like and move on to the policy elements. To be specific, head over to Policy Elements / Authorization and Permission / Network Access / Authorization Profiles. Create a new profile, name it whatever you'd like, mine is called BU-authprofile-rw (to reflect the powers this group has). After the General tab, you can leave the Common Tasks at default, and head over to the RADIUS Attributes tab. This is where the magic happens. You need to define two custom RADIUS attributes and values to be returned upon successful authentication. These are seen below.
The attributes are case sensitive. The value for PaloAlto-Panorama-Admin-Access-Domain should be BU-inet-all, the same thing you named your access domain as. Be case sensitive. The value for PaloAlto-Panorama-Admin-Role should be Device-Group-Full-Access or whatever you named your admin role in the previous steps. Again, this is case sensitive.
Now we're almost good. Now the RADIUS knows what to return to Panorama, we just need to tell it to do so. This should happen whenever there is a successful authentication with a user who belongs to a certain group. This is done under Access Policies / Access Services. Start with Service Selection Rules. Now I assume all your PA devices belong to the same service group. In my case, all devices belong to a service group which is named after the vendor, so all PA firewalls belong to the Palo Alto service group. Therefore, I have an access policy named Palo_RADIUS, which is triggered by the following Service Selection Rule:
As you can see the resulting service is called Palo Alto, and the conditions are quite simple. The protocol is Radius and the AAA client (the network device) in question belongs to the Palo Alto service group. Let's explore that this Palo Alto service is. The only interesting part is the Authorization menu. In this, you need to create an access policy as follows:
The name can be BU-fullaccess, and there is only one condition: the user needs to be in a specific group. In this case: BU AdminRWGroup. The there is one result: the resulting authorization profile is the BU authprofile-rw.
This is it. Now we have the user with his password, in a group, authenticating to a palo alto firewall. If this happens and succeeds, two custom AVPs will be returned to panorama which will act on it. The result? The user will have full privileges because the panorama knows what to do with the received attribute.
Bear in mind that if you run version 5.x or lower on panorama, the user will not have the right to commit the changes to panorama. It will have the rights to commit to the device group only. This is a bug on panorama and is corrected in 6.0.4.
Enjoy!
