One. Firewalls have come a long way.
They don't just allow
and block traffic based on IP addresses and port information anymore.
Among other things, firewalls can filter traffic
by checking who you are and what groups you're in.
In a Palo Alto firewall, this is called user ID,
and we're going to see how this works.
Traditional firewalls, look at IP addresses and ports
and will allow or block traffic based on that generally.
Applications were allowed based on the port they would use
and users were allowed based on their IP addresses
For a while now, we've had NexGen firewalls.
They can permit or deny traffic based on a larger range of information
like application and user information
on a Palo Alto firewall.
The user ID feature collects usernames and group membership from your network.
We can then create security policies to control traffic based on that.
Let me show you what I mean.
We might have an Active Directory domain that contains all of our users and groups.
We then create a group of users who are allowed to access web mail.
A security policy references this group
and allows web mail applications for these users.
While the rest are denied.
This is handy as other I.T.
staff can update this group without needing to get us
as the security administrators involved
There are three primary advantages to this approach.
We can see if a particular user is using risky apps
or if a user is doing something they shouldn't
We can control access to resources based on users and groups,
as well as limiting the transfer of sensitive data.
And if there is a security incident, we can find out which users were involved.
Let's look at what we need to implement user ID.
We look at how it works first, and then we'll look at some configuration later.
The first part of the puzzle
is collecting a list of users and groups in your environment.
This must be collected from a directory service
such as Active Directory using LDAP or an API.
This means that the firewall needs to authenticate with the directory service
so you will need a suitable service account.
Once we have a list of users, the firewall needs to map traffic
to those uses.
Bittrex Source and destination IP addresses and airlines that traffic
to a user.
This may sound simple, but it can be tricky.
After all, IP can be dynamic.
Think of DHCP, for example.
And on top of that, a single user may have more than one device
to cope with this.
The firewall has several methods of mapping traffic to users.
The methods that you use will depend on your environment.
The options available to you include integration with Active Directory
and Exchange or some other directory service
If you have terminal services or Citrix setup,
you can put an agent on each server.
You can display a captive portal to users when they try to access resources
which requires them to enter a username and password.
If you have logging through radius, the firewall can pass
syslog messages for log on and log off events
If you're using global protect, that's clearly a place
where a Palo Alto firewall can natively collect user information.
If there's a proxy server in your environment,
you can append particular headers to the HTP traffic
as the traffic passes through the firewall.
It can read the user info from the headers
and finally, this client probing
where the firewall queries each client for user information.
However, client probing is not a recommended approach anymore.
So all this is great, but there is a catch.
As we've seen, users are matched to IP addresses.
If you have not in your environment IP may be changed
before the firewall sees them, which can break user ID.
Keep this in mind when you're planning your deployment.
The firewall can use the server and security logs
from a domain controller or exchange server to see who is logging on
and from which IP addresses they're logging on from.
This is done with an agent.
There are two types of agent.
The first type is the Windows agent, which is installed on a domain member server.
It does not need to be installed directly on the domain controller or
exchange server.
When a
user logs in the domain controller logs this information,
the server agent periodically asks the service for these logs,
which it uses to build a list of users and IP address mappings,
which it then sends back to the firewall
for this to work, each domain controller must be configured
to log successful logging events.
This can be combined with a feature called credential detection
This detects where the corporate account
details are being used to log onto specific websites.
However, this is out of scope of our video.
An alternative to this is the Pan agent.
It runs natively on the firewall.
This doesn't need to be installed is just already there.
This follows the same principle as the Windows agent.
It puts a little more load on the firewall, but it's a bit simpler.
So it may be better for small networks
if you have
remote sites with domain controllers and exchange servers,
or you have multiple Palo Alto firewalls running user ID.
You probably want to use the Windows agent
if you have terminal services or then up.
There's a different agent you can install on each of these servers.
The trouble with these type of servers is that there are multiple users
but they all have a single source IP that is the IP of the server.
So when a user logs in this agent allocates a range of ports
to the user and reports this back to the firewall.
All of that uses traffic will come from one of these ports.
So the firewall can
then map the source IP and port combination to that particular user.
If you have users that aren't in a directory,
perhaps guests or local Linux users, you might consider using a captive portal.
This displays a web based log on page
when a user tries to access a network resource.
The user can authenticate here and will be allowed or denied access
This is quite flexible and can incorporate single sign on
and tlm SAML multifactor
authentication client certificates and more
If you have a wi fi deployment,
the controller will probably use radius to authenticate users.
What we can do here is configure the controller
to send this log messages to the firewall.
The firewall can then pass these messages for the log on and log
onto information and collect the user to IP mapping.
Log off information is included to keep these mappings fresh.
This isn't just limited to.
Of course it can be used for any radius or eight or 2.1 X enabled device.
As long as these logs can be used.
We could run into trouble if
we're using a proxy server for internet access. Why?
It's common for proxy servers to use their own IP
addresses, not the real IP of the client.
This would make it appear that all the users have the same IP address
to resolve this issue.
The proxy server can be configured to add the x forwarded for header.
If you're not familiar with this, this is where additional information
is embedded into the FTP request.
The X forwarded for header contains the IP address of the original client.
When the request passes through the firewall,
the firewall reads this header to get the user to IP mapping.
For security,
this header can optionally be stripped out before sending the IP request
to the internet.
The last type of user mapping is client probing.
This uses WMI or Netbios to query
clients for information at regular intervals.
This is considered a legacy solution.
The other methods we've talked about should be used whenever possible instead.
This is considered legacy for two reasons.
First, this can generate an unnecessarily large amount of traffic.
Second, it has potential to leak client information,
which is of course, a security risk.
Let's start preparing for our user ID deployment.
There are three areas that we're going to look at in this section.
We'll think about the mapping methods that we'll use in our environment.
We'll look at the server's account requirements,
and we'll see how to configure LDAP to collect users and groups
when selecting the methods that we want to use.
Start by considering where the users are logging in from.
Specifically thinking about the zones and subnets that the uses are in
the user's inactive directory.
Do you have some other directory service?
Do you have Linux servers with local accounts?
What about multi access systems?
Do you have any terminal servers or Xen up services in your environment?
Is Redis or tactics used anywhere?
This could be for administration for Wi-Fi
for device authentication or something else.
If you're using radius, is it integrated into Active Directory or is it standalone?
How do you access the internet Is there a proxy server involved somewhere?
And remember, finally, to never use client probing
next you will need one or more service accounts.
I use one service account for all tasks, which includes LDAP
queries as well as the Windows agent or PIN OS agent.
You may prefer to use a separate account for each task.
There are several permissions that need to be configured
and assigned to the service account, which are summarized here.
Once server's account is ready,
you can think about LDAP configuration.
This allows the firewall
to collect user and group information from your directory service.
Just remember this only collects a list of usernames in groups.
It does not map IP addresses to users, yet
there are two parts to LDAP config enabled that profile
and binding the profile to user ID.
For our example, we're going to configure LDAP for Active Directory.
We can have up to four domain controllers in each profile
to add a domain controller into the name.
The IP address and the LDAP port that you want to use.
The port is probably 389 or 636
depending if you use regular LDAP or secure LDAP.
If you're using secure LDAP,
make sure you enable it with the box at the bottom on the right.
We select the type of directory service we're using, which is Active Directory.
In this case,
you need to put in the Bastion, which is part of the LDAP query.
This is a path to where the users are within the domain.
This could point to the root of the domain or to a specific value.
The bind Dean is the service account that you created earlier.
This can be entered in the domain slash username format
or as even like I have done here.
You can change the times
if you want, but generally it's best to leave them as they are.
Now we have the profile.
We can map it to user ID with group mapping
For the most part, I leave these settings as default,
only specifying the LDAP profile and making sure it's enabled
the user domain.
For example, can be automatically detected.
But if we want to, we can override it with the settings here.
This is also where you would add in filters.
If you want user ID to work only with particular groups.
Let's take a look at configuring the Windows agent
to collect logging events.
Step one is to download the Windows Agent installer from the Palo
Alto Support Portal.
You will need a valid log for this.
Find the version that's closest to the version of your firewall
Notice how there are two files.
One is for credential detection, which is an entirely different technology.
Next, install the agent on your domain members server.
I don't recommend installing this directly on the domain controller
or exchange server.
The install is easy, so I won't show you that part.
If you have branch sites with their own domain controllers
or exchange servers, you should consider installing an agent at each site.
The reason for this is performance.
The agent will collect full logs from the Windows servers,
not just log on and log off events.
However, they will only send a summary of these logs to the firewall,
which is less load on the way links when you're done.
Grant these servers account full access to the installation folder
in the app under user ID and setup.
We can enter our service account details
under Discovery and the servers that we want to monitor.
The simplest way is to click auto discover
and then to manually add anything that's missing.
You'll probably find that domain controllers will work
automatically while exchange servers will need to be added
This is also where you would add other information sources
if you have them like a CIS log listener or a Novell server.
The best practice is to list the subnets
that your users will log in from and exclude all others.
I'm not going to be doing that for this demo.
Finally, commit your changes just like you would on the final
I have found that it often says not responding for a while during commit.
You can verify your settings in the user ID tab.
Check that your service is running and that the servers are connected.
If it's not connected, you may have to go back and check
the configuration of the service account.
We also need to configure the firewall to integrate with the agent.
They can be more than one agent on each firewall
and multiple firewalls can use the same agent
We simply need to enter the IP address of the agent
and the part that is running on.
That's 5007 by default.
And of course, don't forget to commit your changes when you're done.
Nearly done.
So far we've collected a list of users.
We've added a method of mapping traffic to those users.
Now it's time we did something with that information.
Our first task is to enable user ID.
This is done per zone.
It should only be enabled on trusted zones.
User idea information is really used in the security policy.
This is just like any other security rule.
However, the user or group is added as the source of the traffic.
Everything else is configured as normal.
As a matter of best practice, we should create a security policy
to stop user ID traffic from leaking outside the network.
To do this, create a rule to allow the Palo
Alto User ID agent application from agents and servers
that we're monitoring only between trusted zones.
Then create another rule to block this application to all other locations.
If you're using high availability,
confirm that config sync is enabled.
This is really optional, but it helps over to complete as fast as possible.
There are two ways we can confirm this is working.
Initially, we can see the user two IP mapping from the web console.
We can take a look at the other traffic logs This will show as traffic
as normal as well as usernames associated with this traffic.
Keep in mind that your
security policies need to be configured with logging to see this,
and that's how you configure user I.D.
on your Palo Alto firewall.
This really does add a deeper level of security to your network.