How to Set Up Active Directory Integration on a Palo Alto Networks Firewall

Posted by Charles Buege on Jun 25, 2020 11:08:00 AM

Thursday, June 25, 2020

By Charles Buege, Fuel User Group Member

When you’re setting up a Palo Alto Networks firewall, after getting the initial IP address configured for the management interface, setting up integration into other servers in your environment is a very common, early step. This article will go into the necessary steps to set up Lightweight Directory Access Protocol (LDAP) integration into an Active Directory environment.

Here is the information for the Active Directory environment that we are going to use for this article.

NetBIOS/Domain Name: StarGateCommand

LDAP Domain: DC=sgc,DC=org

Active Directory Users:

Sam Carter, sam.carter@sgc.org

Palo User, palo.user@sgc.org

Active Directory Group:

GlobalProtect VPN Users

Add LDAP Server Profile

Here are the steps for creating the LDAP Server Profile:

Go to Device -> Server Profiles -> LDAP.

Click “Add”.

Here is the blank LDAP Server Profile screen:

Image001

Here are the values for the fields that I will be using for this screen:

Profile Name: SGC LDAP Profile

Server List: Click “Add” in this section and add the following two entries:

Name: SGC-DC01, LDAP Server: 10.241.200.1

Name: SGC-DC02, LDAP Server: 10.241.200.2

In my case, I’m going to leave the default port of 389 the same for both entries.

Next, skip near the end of the screen and uncheck the box for “Require SSL/TLS secured communication.” By doing this, you’ll be able to immediately do a lookup on the LDAP servers when it comes to specify the “Base DN” that you’ll be connecting to.

Set “Type” to “active-directory.”

Click on the drop-down box for “Bind DN” and if you entered your “LDAP Server List” information correctly and are on a subnet where the management interface of your firewall is able to communicate with the LDAP server(s) you added, your Bind DN should drop down and be selectable. In my case, it is “DC=sgc,DC=org.”

For “Bind DN,” enter a user ID in your Active Directory infrastructure that you’ll use to make lookups into your Active Directory. The account you are going to use only needs to be a basic member of the domain – no group memberships like ‘Domain Admins’ are necessary — just “Domain Users” is sufficient.

Note: Be sure to note that if your password policy requires periodic changing of passwords and/or expiring accounts that you take this into account when selecting the user ID you want to use for this task. If this ID expires or the password changes, you’ll need to remember to come into this screen and update this information.

Enter the user’s password in the “Password” and “Confirm Password” boxes.

Click “Ok” to add the LDAP Profile to your system. Here is my completed entry:

Image002

Add Group Mapping

The next thing that I do to verify that my Active Directory infrastructure is being accessed and read, is to add a “Group Mapping” to the system.

Go to Device -> User Identification -> Group Mapping Settings.

Click “Add.”

Here is the blank Group Mapping screen:

Image003

Here are the values for the fields that I will be using for this screen:

Name: SGC Group Mapping

Server Profile: SGC LDAP Profile

User Domain: StarGateCommand

Click on the “Group Include List.” With your LDAP entry from your LDAP Server Profile listed in the “Available Groups” on the left, if you click the triangle next to the LDAP entry and expand your AD infrastructure, you should be able to expand the “cn=users” LDAP directory and see the groups in your Active Directory Domain.

Note that since this is the “Available Groups” section, all you are seeing is Groups — no users will be listed.

There’s no need to select any Groups to add to the “Included Groups” option here — we will be controlling our access via Active Directory groups in other ways. Click “Ok” to save your screen.

Here is my completed entry:

Image004

Image005

At this time, you’ll want to make your first commit to your firewall for this sequence. By performing a commit now, when we get to the next step of adding Authentication Profiles, you will have greater insight and confirmation that your steps have been working so far. Click “Commit” and then “Ok.”

Once the commit has completed, you will add your “Authentication Profile.”

Add Authentication Profile

Go to Device -> Authentication Profile.

Click “Add.”

Here is the blank “Authentication Profile” screen:

Image006

Here are the values for the fields that I will be using for this screen:

Type: LDAP

Server Profile: SGC LDAP Profile

Login Attribute: sAMAccountName

Note: This is properly spelled and proper case. Enter the “Login Attribute” EXACTLY as shown above.

User Domain: StarGateCommand

Click on the “Advanced” tab.

Click the “Add” button.

You will now see a full list of all your users and groups both as defined on your firewall, as well as a lookup in your Active Directory infrastructure. If you don’t do the commit mentioned above, you will not see your Active Directory elements in this list. While you could select individual groups at this point as well, you aren’t going to do that here. Select “All,” which should be at the top of your list, and then click “Ok.”

Here is my completed entry:

Image007

Image008

Add Authentication Sequence (Optional Step)

One item I need to interject at this point is the possible need to authenticate against multiple systems — more than one Active Directory infrastructure, Active Directory authentication as well as local firewall authentication, etc. The steps outlined later are presuming a one-to-one ratio of steps in the process. If you will have the same GlobalProtect Gateway and Portal needing to authenticate against multiple systems, here is where you will define an “Authentication Sequence.” This step will list the order in which you will want to check for authentication information against the different systems. In my example, I will only be using LDAP, so I won’t need an Authentication Sequence setup, but I do want to show you how to create one if you do need it.

Go to Device -> Authentication Sequence.

Click “Add.”

Here is the blank “Authentication Sequence” screen:

Image009

Let’s say beyond the “SGC Auth Profile” I also have a local Authentication Profile called “GP VPN Users Auth Profile” that has the users I have defined locally on my firewall as valid VPN IDs. Here is how I would create the Authentication Sequence:

Name: SGC then GP Auth Sequence

Under “Authentication Profiles”, click “Add.”

First select the “SGC Auth Profile,” click “Add” again, and then select the “GP VPN Users Auth Profile” so your screen looks like this:

Image010

Notice a couple of things on this screen:

  1. Since I added the Authentication Profiles in the order I listed, that is the order they are in. This is one time that when order DOES matter when adding things to a list like this.
  2. Once you added the second Authentication Profile, the buttons at the bottom of the screen “Move Up” and “Move Down” became enabled.

So, if by chance you added the two steps out of order, that’s fine, but keep in mind as I said a moment ago, the order DOES matter. This means if you have a user, for example, “bob,” listed both in the “SGC Auth Profile,” as well as in the “GP VPN Users Auth Profile,” the match will be made to the “SGC Auth Profile’s” “bob” entry first and won’t move onto the second one.

As far as the rest of the steps in this sequence, if you are going to use an “Authentication Sequence,” instead of selecting an “Authentication Profile” for the rest of these steps, instead select your “Authentication Sequence” and it will work in the same manner as an “Authentication Profile.”

Add an Active Directory “Superuser”

Moving forward, you can now add an Active Directory user to your system and have their Active Directory credentials be the same as their login for the web interface of the firewall administration.

Go to Device -> Administrators.

Click “Add.”

Here is the blank Administrator screen:

Image011

For the “Name,” enter the user’s Active Directory “account” name. This must match exactly so the Palo Alto Firewall can do a proper lookup against your Active Directory infrastructure to check the authentication against the correct ID. In this example, I entered “sam.carter.”

Authentication Profile: SGC Auth Profile

In my example, I want “sam.carter” to be a “Superuser.” If you do not want this person to be a “Superuser” change the “Administrator Type” to whatever you’d prefer.

Click “Ok” when complete.

Here is my completed entry:

Image012

At this time, you can commit your changes to your firewall and test this new user’s access to your system. They will be able to go to your firewall’s web interface and log in with their Active Directory credentials. These credentials are not cached on your firewall. Each time someone logs in with them, their credentials are verified.

Add Active Directory Access to GlobalProtect

Now you can setup GlobalProtect to allow users who are a member of the Active Directory group “GlobalProtect VPN Users” to be able to VPN into the system. To do this, change the settings for the GlobalProtect Portal and Gateway.

Go to Network -> GlobalProtect -> Portals.

Click on your existing Portal configuration.

Click on the “Authentication” tab.

Here is what the blank “Client Authentication” screen for the GlobalProtect Portal Configuration looks like:

Image013

Here are the values for the fields that I will be using for this screen:

Name: SGC GP Portal Client Auth

Note: The reason I went with a longer name like this, including the word “Portal” in the name, is so if I do look at the configuration file for the firewall, it will be easier to distinguish this information from what I will set in the GlobalProtect Gateway. You will notice it is very similar.

Authentication Profile: SGC Auth Profile

Allow Authentication with User Credentials OR Client Certificate: Yes

Click “Ok” when complete.

Here is my completed entry:

Image014

Once back at the GlobalProtect Portal Configuration screen, it should look like this:

Image015

Next, click on the “Agent” tab.

Click “Add.”

Here is what the blank “Configs” screen for a GlobalProtect Portal Agent looks like:

Image016

Here are the values for the fields that I will be using for this screen:

Name: SGC GP Portal Agent Auth

Here is where we limit those users in our Active Directory to who can and cannot connect to our system. If they are not a member of this group, they won’t be able to connect to the portal.

Click on the “Config Selection Criteria.” Under “User/User Group,” click “Add.” I then type the word “global” in the filter screen and reduce the selection list down to the one group I’m looking for.

Here is what the item looks like:

Image017

Once you select the group, you will see that the group’s name changes from its NetBIOS name to its LDAP name. Here is what this looks like:

Image018

Next, click on the “External” tab.

Click “Add.”

Here is what the “External Gateway” screen looks like:

Image19-1

This screen will need to be filled in by you as your system has been defined. My screen looks like this with the address blocked out:

Image020

Back at the “External” tab of the “Configs” screen, with the “Address” blocked out, your screen should look like this:

Image021

Click “Ok” when complete.

Back at the “GlobalProtect Portal Configuration” screen, your screen should look like this:

Image022

Click “Ok” when complete and you will be back at the GlobalProtect -> Portals screen.

Go to Network -> GlobalProtect -> Gateways.

Click on your existing Gateway configuration.

Click on the “Authentication” tab.

Here is what the blank “Client Authentication” screen for the GlobalProtect Gateway Configuration looks like:

Image023

Here are the values for the fields that I will be using for this screen:

Name: SGC GP Gateway Client Auth

Authentication Profile: SGC Auth Profile

Allow Authentication with User Credentials OR Client Certificate: Yes.

Click “Ok” when complete.

Here is my completed entry:

Image024

Once back at the GlobalProtect Gateway Configuration screen, it should look like this:

Image025

Next, click on the “Agent” tab.

Click on the “Client Settings” tab.

Here is what the blank “Configs” screen for a GlobalProtect Gateway Agent looks like:

Image026

Here are the values for the fields that I will be using for this screen:

Name: SGC GP Gateway Agent Config

Config Selection Criteria -> Source User section, click “Add.”

This is where we further limit the GlobalProtect Gateway as to what users can and cannot connect via the Active Directory group. This is the same group that we specified when we did the Agent definition for the Portal a couple of steps back.

I type the word “global” in the filter screen and reduce the selection list down to the one group I’m looking for. Here is what the item looks like:

Image027

Once I select the group, you will see that the group’s name changes from its NetBIOS name to its LDAP name just as before. Here is what this looks like:

Image028

Next, as when setting up any VPN configuration, you’ll need to click on the “IP Pools” tab and specify the subnet(s) that will be available to your VPN users.

Here is what this looks like:

Image029

If you’re like me, I also set up split tunneling on my VPN as well. If you don’t set this up, then your users won’t be able to access resources on their home network like printers or other items. Some companies will want to lock this down, but in my case, I don’t want to have this in place.

I click on “Split Tunnel” and add just the subnets in my network that I will want to be accessible to my remote users. Here is what this looks like:

Image030

At this point, you can click “Ok” and you’ll be returned to the GlobalProtect Gateway Configuration screen. Here is what this looks like:

Image031

You’re all set. Perform a “commit” to the firewall and you will be able to have your users connect using the GlobalProtect VPN client and their Active Directory credentials. Just be sure to tell them that when they enter their user ID in the GlobalProtect client that they use their Active Directory ID without the NetBIOS or domain name extension. So, instead of using “sam.carter@sgc.org” as in my user listed here, they’d just need to use “sam.carter.”

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”.

Topics: firewall, Active Directory, active directory integration

Posts by Topic

see all

Subscribe to Blog Updates

Recent Posts

Posts by Topic

see all