Professional Documents
Culture Documents
While these functions may rely on similar settings they are separate processes. And both need
to be configured to apply group based user policy and reporting.
The default behavior of these LDAP queries is that the firewall will connect to the LDAP
server on a configurable interval to gather and maintain group aping. A software agent
system can be configured to proxy the firewall LDAP queries. This can be more efficient
when a large number of firewalls need the same information from the directory, as the agent
will cache the data.
The firewall defines a number of “LDAP Servers” under the User Identification node. Each
LDAP Server instance represents a bind to a specific part of an LDAP tree. It will enumerate
all of the user and group
objects at that point and
below. Filters can be
defined in this
configuration using
standard LDAP syntax to
limit the users and groups
returned. In addition a
list of groups to be
maintained for use in
firewall rules can also be
configured in the Group
Mapping tab. When
enumerating users from
Active Directory, there
will need to be a LDAP
Server configured for
each domain.. Only
LDAP objects that use a
field to list membership
can be used as groups on
the firewall. PAN-OS
does not support the use of container objects such as Organizational Units (OU) as security
principals in firewall policy.
Access credentials to the LDAP tree is specified in a LDAP Authentication server object that is
referenced by the LDAP Server object. The Authentication Server object also specifies which
directory servers will be contacted, the order they will be contacted in and when the firewall
will try the next one on the list. One critical setting from the LDAP Server Profile object is the
LDAP server Type field. Based on the value chosen for this field (Active Directory, eDirectory
or SUN) the values for group mapping using this server will be automatically populated.
When configuring the LDAP server profile the domain name must be provided that will be
prepended to all of the objects learned from this server. This field must be the NetBIOS name
of the domain and should not be the fully qualified domain name of the AD tree. (e.g. CORP
not CORP.local)
The “Base” field represents the point in the LDAP tree that the firewall will connect to and
begin the search for users and groups. The “Bind DN” field contains the user name
If Universal groups are used in Active Directory, a Global Catalog (GC) server must be used
to capture memberships. A GC server is a domain controller for one of the Active Directory
domains that also holds a database containing Universal group membership. To access this
second LDAP database on this server, the LDAP bind must be set to port tcp/3268 rather
than the traditional LDAP port of tcp/389. An important limitation of using a Global Catalog
for Universal Group membership is that only Universal Groups containing individual users
will be able to be successfully enumerated. If the Universal Groups contain other groups then
they will not be fully enumerated and cannot be used for security policy.
Note: In order to support LDAPS (check box ‘SSL’) make sure your Domain Controller is
configured appropriately. Here you can find some useful documentation:
http://technet.microsoft.com/en-us/library/cc725767%28WS.10%29.aspx
http://support.microsoft.com/kb/321051
Domain Global security groups in an Active Directory domain. If the server type field is
configured correctly in the LDAP Auth server object, these fields will then be prepopulated
with the most common settings.
The Group Include List can be used to filter which groups from the LDAP servers are
displayed in the Firewall Policy Interface. This also filters which users are tracked in the
firewall logs. If a user does not belong to one of these groups, the firewall will not record the
users name in the various logs.
2. Filter the list of groups to include only the groups that will be used in firewall policy.
3. Always populate the Domain field with the NetBIOS domain name.
5. For multiple domains, create multiple LDAP server objects, one for each domain.
2. eDirectory monitoring
3. Client Probing
4. Captive Portal
7. User-ID API
These events will contain a user and IP address. Only Allowed IP ranges (as configured on the
User-ID agent or on the firewall agent) will be recorded. If the file ignore_user_list.txt is
present in the Agent installation folder the mapped user name will be compared to the list of
names in the file. The firewall also maintains a list that is populated with the CLI command
“set user-id-collector ignore-user …”. If the name matches one of the entries, the Agent will
discard the data. Once the username to IP mapping is created, the agent will send this data to
the firewall. The default timing for checking new log events is every second, but this timer is
configurable. Note that these events will only be present in the security log if the AD domain
is configured to log successful Account Logon events.
Reading security logs causes very little overhead for a Domain Controller or an Exchange
server and is a highly effective method of mapping users in a Microsoft environment. The
mappings will be maintained for a configurable time out. For environments using session
monitoring this timeout is recommended to be set at 120 min as that is the longest a client
will go before checking the sysvol share for new GPO. If no session monitoring is configured
the recommended value is half the DHCP lease time used in the environment. Client systems
in an AD domain using the default configuration will attempt to renew their tickets every 10
hours.
The account that the agent uses to login to the domain controller must have rights to read the
security log. In Windows 2008 and later domains, there is a built in group called “Event Log
Readers” that will provide sufficient rights for the agent. In prior versions of Windows, the
account must be given the “Audit and manage security log” user right through group policy.
Making the account a member of the Domain Administrators group will also provide rights
for all operations. The hardware agent will also require the right to make queries over the
WMI as it uses the WMI to read logs.
In the normal operations of an AD domain, users on Windows systems will connect to the
sysvol share on the domain controller to check for new Group Policy Objects. The default
timing for this is 90 minutes with a +/- 30 minute offset. For users connected to the network
during a regular work day this process will insure that they remain mapped throughout the
day.
Specific users can be ignored by the agent using one of the methods mentioned previously.
Membership in the Server Operators built-in group will provide the correct level of access for
the agent to perform this task.
• 2 seconds: Get list of new IP / user mapping from agent. This is a delta of new
mapping only.
• 2 seconds: Send list of unknown IP addresses that were encountered in traffic to the
agent.
• 5 seconds: Get agent status. This is a heartbeat used to determine the status of each
configured agent.
eDirectory Monitoring
The User-ID agent can access an eDirectory tree and read the logged in IP for each user.
When the user logs in to eDirectory, the IP address of the end point is stored in the directory
as a field in the user object. This serves a similar function as the AD monitoring log scraping
and only works with eDirectory.
eDirectory servers are configured in the same monitoring interface as the AD and Exchange
servers. The same cache time out will apply to mapping learned from the eDirectory server.
Unlike Windows security logs, the user IP data in eDirectory is replicated through the
directory. This means that a single eDirectory server can be queried for all users.
WMI/NetBIOS Probes
Log reading is effectively a passive method of user mapping, while probing is an active
method. On a configurable interval, the User-ID Agent will send a probe to each learned IP
address in its list to verify that the same user is still logged in. The results of the probe will be
used to update the record on the agent and then be passed on to the firewall. Each learned IP
will be probed once per interval period. It’s important to make sure that large environments
have a long enough interval for all IP’s to be probed. For example, in a network with 6,000
users and an interval of 10 minutes, that would require 10 WMI requests a second from each
agent. These probes are queued and processed by the agent as needed.
In addition, when the firewall receives traffic on an interface in a zone with User
Identification enabled that is from an IP address that has no user data associated with it, the
firewall will send the IP to all the AD agents configured and will request them to probe in
order to determine the user. This request will be added to the queue along with the known IP
addresses waiting to be polled. If the Agent is able to determine the user IP based on the
probe, the information will be sent back to the firewall.
NetBIOS probes have no authentication and do not require any specific group membership of
the Agent account. A drawback to NetBIOS is that it is not very reliable across larger
networks; it is commonly blocked by host based firewalls and will not work for certain
modern operating systems (Anything with NetBIOS over TCP disabled).
WMI queries are much more reliable and are secured by either NTLM or Kerberos based
authentication. To perform these queries successfully, the agent account needs permissions to
read the CIMV2 namespace on the client systems. By default, only Domain Administrators
have this permission. The underlying WMI query that is sent can be simulated with the
following command, where remotecomputer would be the IP address of the system being
probed:
The firewall agent can only use WMI for client probing.
Captive Portal
Captive portal is traditionally used to identify users that have slipped through the other
methods of identification or for environments where the other methods are not appropriate.
It is an identification method that is invoked if there is no user information for HTTP based
traffic that the firewall encounters. If a user has been mapped by one of the other possible
methods, Captive Portal will not be triggered. Captive portal will only be triggered by a
session that matches the following criteria:
2. The session is HTTP traffic (note that this traffic can be on any port, but must be
HTTP).
When captive portal is triggered, the browser session is interrupted by the firewall and user
credentials are requested. Once the user is identified, they will remain mapped until either an
idle time out or hard time out is reached. At that point the user mapping is removed and
Captive Portal may be triggered again.
For firewalls deployed in L2 or Virtual Wire mode, Captive Portal must be configured
transparently. In this configuration the firewall will spoof the destination address for use in
authentication. This can generate certificate errors when the users credentials are prompted
for using SSL. A more flexible method is a redirect Captive Portal, where the firewall uses a
302 HTTP error code to redirect the user to a L3 interface owned by the firewall. When using
a Captive Portal redirect, a specific SSL certificate can be installed for the portal to mitigate
any certificate warnings. In addition, Captive Portal redirect can use cookies to mark the
session. This will allow the session to remain mapped even after the time outs have expired.
Finally, Captive Portal redirects with cookies can support users that roam from one IP
There are three methods for the firewall to extract user data from the browser:
1. NTLM Authentication
3. Certificate-based Authentication
NTLM Authentication
Microsoft clients can participate in a NTLM challenge and response exchange that consists of
3 messages. The browser will use the credentials of the currently signed in user. Internet
Explorer will do this be default and Firefox can be configured to do this for specific URI’s. (In
the about:config set the network.automatic-ntlm-auth.trusted-uris value to the captive portal
URI) This authentication is transparent to the user. The user name captured from this method
is the NetBIOS name in the form of DOMAIN\USER and it will be mapped to the
appropriate user ID if the LDAP Server configured to read the AD domain has the correct
value in the domain field. If the browser or operating system does not support NTLM
authentication, the firewall will fall back to the next form of Captive Portal. When
configuring NTLM based authentication for Captive Portal a host name must be provided.
For NTLM to work, this host name must not be fully qualified. For example, if the DNS
name of the portal is portal1.company.com, and company.com is in the users search suffix,
the correct vale for the NTLM host would be “portal1”.
2. If using RADIUS, ensure that the proper default domain is configured for the users. If
no domain is provided during login, the default domain will be assumed.
User-ID API
An API exists that can feed user to IP mapping information into the agent. This API can both
add and remove user IP mappings. The API can be used when the traditional methods of log
scraping and WMI probing are not ideal for the environment. Some examples of the API that
can be found on Dev Center (https://live.paloaltonetworks.com/community/devcenter) are:
3. Modules for NAC appliances that pass on user and IP information to the firewall.
See Dev Center for specific examples and scripts concerning the User Identification XML API.
Use the tags “user-id” and ‘api” in your search.