Thursday, October 1, 2020
By Charles Buege, Fuel User Group Member
When working on your Palo Alto Networks Firewall with Active Directory Integration, you may find it occasionally necessary to grant access to some users who need certain levels of access, but not full access. In my case, I recently had two specific instances where I needed to grant two different people these levels of administrative access:
The ability to add custom URLs into our system.
The ability to view, but not modify, all aspects of the firewall. This included running reports, queries for users, etc., but not allowing the person the access to actually make changes to the firewall.
In cases like these, Admin Roles are exactly what you want to employ.
In this article, we will go through the process of setting up a custom “Admin Role” and assigning it to an Active Directory user that will be created for just this task. (If you’re just joining us, take a look at my previous article, “How to Set Up Active Directory Integration on a Palo Alto Networks Firewall.”)
Here is the information for the configuration that we will use for this article:
Active Directory Users:
Bill Lee, firstname.lastname@example.org
Jack O'Neill, email@example.com
Palo Alto Networks “Admin Roles”:
Custom URLs Admin Role
Read Only Access Admin Role
A Note on Organization and Naming
Before we dive in, it’s worth noting that while adding the descriptor of “Admin Role” to the end of each role may seem redundant, there is a reason for this. In the near future, I plan to also share an article on how to utilize API calls to make changes to Palo Alto Networks firewalls. By having the extra descriptor of “Admin Role” at the end of each, my intention is to know for sure that this is the “Admin Role” option and not another option selected by accident.
Additionally, I’m a big proponent of self-documenting code and configurations. Should someone need to perform an export of the XML data for this configuration, it will be clear as someone is reading through the configuration file that they are in the “Admin Roles” section.
Let’s take a look at how to set up admin roles for each of these users, to allow them access to just the resources you want them to have.
Adding Admin Roles
Here are the steps to add an Admin Role:
Go to Device -> Admin Roles.
Under “Name,” enter the name for the Admin Role you are creating. In my case, I will start with “Custom URLs Admin Role.” For this Admin Role, the ONLY thing that I want any users to be able to do is to be able to modify the URL Categories.
To do this, I will take and disable all of the Web UI options except Custom Objects -> URL Category. Additionally, since I want this user to be able to make the actual change persist on the firewall, I will also grant them the ability to “Commit” to the firewall. Here is what the screen will look like for this:
Once complete, I click “Ok.”
As you are proceeding through the list and disabling the permissions you want turned off for this user, you will come across something that may be unclear until you see it. Several of the permissions in the “Web UI” tab have two toggle permissions and other options have three toggle permissions. The permissions are as follows:
Enable: The user can make changes with this permission.
Read Only: The user can view details of a given selection but cannot make any changes.
Disable: The user cannot make changes, view these options or even see the menu option in the web user interface. Further, this means for the Admin Role of “Custom URLs Admin Role,” the only option that the user will see in the UI will be “Custom URLs” – all other options won’t even be listed.
As mentioned earlier, some roles will have Enable and Disable, while other options will have all three available to them. This is because for some options, “Read Only” isn’t applicable. For example, when you are going to Monitor -> Logs -> System, there are no “changes” that can be made to this selection, hence the lack of the “Read Only” permission. In this case, you’ll just toggle back and forth between “Enable” and “Disable.” Until you are more familiar with each of the permissions, I recommend clicking through all available permissions to make sure you’re setting the correct selections to each option. This will be very important to the next Admin Role that we are going to create, “Read Only Access Admin Role.”
Creating the “Read Only Access Admin Role”
To create the “Read Only Access Admin Role,” click on “New” at the bottom of the screen and add the name “Read Only Access Admin Role.”
Going through each of the permissions here, I will make sure that whenever there is an option where a change could be made, I will cycle through each of these options and set them to “Read Only.” If “Read Only” isn’t available, I will then set them to “Enable.”
The only exception to this is that I will set the permission for “Commit” to “Disable,” so the read only user can’t even attempt to send a commit to the firewall, even by accident. Here are two screen shots of what the final configuration will look like:
In Figure 02, you can see that several of the options selected are set for “Enable,” while several others are set to “Read Only.” As detailed earlier, options like “App Scope,” for example, don’t have a “Read Only” permission, so it is set to “Enable.” “Botnet,” on the other hand, does have options that the user can specify, so that permission is set to “Read Only.”
In Figure 03, as mentioned previously, “Commit” is disabled so the user can’t even accidentally perform a commit of the firewall.
Now that the roles are created, let’s get the users defined in the firewall so they can log in and see their options.
Creating Users in Firewall
Go to Device -> Administrators.
For the “Name” of the user, mimic the user’s Active Directory user ID. In this example, it will be “bill.lee.”
For the “Authentication Profile,” we will select “SGC Auth Profile,” created in the previous article.
Finally, we will limit what Bill can do in the system by specifying the role that he has access to. Click on “Role Based” instead of “Dynamic” under the list of “Administrator Types.” Then, from the newly shown “Profile” drop-down list, we select the role that we want to assign to Bill — “Custom URLs Admin Role.”
Here is what the screen looks like:
After that, click “Ok.”
For the other user, Jack O’Neill, we will allow him read-only access to all of the possible options on the firewall. This will allow him the rights to see everything that is in place, but it protects the system from him making any lasting changes. This means that the administrator, sam.carter, has less to worry about with regards to Jack accidentally making incorrect changes to the system and breaking everything.
To add Jack:
Click "Add" at the bottom of the screen
For Name, enter “jack.oneill”
Set the “Authentication Profile” to “SGC Auth Profile”
Set “Administrator Type” to “Role Based”
Set “Profile” to “Read Only Access Admin Role”
Here is what the screen looks like:
Once complete, click “Ok.”
Now we perform the commit to push the changes to the firewall. Click “Commit” and then “Ok.”
Once the commit is complete, let’s see what each person’s interface looks like. First, we start with Bill Lee.
Logging into the UI as Bill, we get this screen available to us:
Since everything else for Bill was disabled, the firewall is only showing the option of “Custom URLs” to him. No other options are available.
Now we move over to Jack’s view. Here is what Jack sees when he goes to Policies -> Security.
Everything looks normal for a user, correct? Not quite. Here are a couple obvious differences right off the bat. First, look at the “Add” option at the bottom left corner of the screen:
See that the “Add” option is greyed out? If Jack tries to click on it, nothing happens. The option is disabled for him.
Next, let’s look at the commit option in the top right corner of the screen:
With this setup in place, you’re ready to move forward with admin roles for Active Directory users with different controls to their level of access on the firewall.
Charles Buege is the senior DevOps engineer for Temeda, an Industrial IoT company out of Naperville, Illinois. He currently holds a PCNSA certification and is working towards his PCNSE. He also runs an IT-based meetup group called “The IT Crowd”.
More to Explore
Check out these Fuel blog posts for further reading: