Best Practices for Securing User-ID Deployments

by ggarrison on ‎09-16-2014 04:21 PM - edited on ‎09-21-2016 05:16 AM by (49,852 Views)

Overview

User-ID services enables mapping of IP addresses to users, and when enabled gives network administrators granular controls over what various users are allowed to do when filtered by a Palo Alto Networks Next-Generation Firewall.  As with enabling any network services, following best practices and configuration guidelines when deploying User-ID can help to reduce and eliminate exposure to potential risk.  This article is intended to help network and security administrators avoid misconfiguration and safely enable User-ID services in network environments.

 

 

Details

Only enable User-ID on trusted zones

By only enabling User-ID on internal and trusted zones, there is no exposure of these services to the Internet, which helps to keep this service protected from any potential attacks.  If User-ID and WMI probing are enabled on an external untrusted zone (such as the Internet), probes could be sent outside your protected network, resulting in an information disclosure of the User-ID Agent service account name, domain name, and encrypted password hash.  This information has the potential to be cracked and exploited by an attacker to gain unauthorized access to protected resources.  For this important reason, User-ID should never be enabled on an untrusted zone.

 

.

 

Specify included and excluded networks when configuring User-ID

The include and exclude lists available on the User-ID Agent as well as agentless User-ID on PAN firewalls can be used to limit the scope of User-ID.  Typically, administrators are only concerned with the portion of IP address space used in their organization.  By explicitly specifying networks to be included with or excluded from User-ID, we can help to ensure that only trusted and company-owned assets are probed, and that no unwanted mappings will be created unexpectedly.

 

.

 

Disable WMI probing in high security networks

WMI, or Windows Management Instrumentation, is a mechanism that can be used to actively probe managed Windows systems to learn IP-user mappings.  Because WMI probing trusts data reported back from the endpoint, it is not a recommended method of obtaining User-ID information in a high security network.  It is also usually not necessary.  In environments containing relatively static IP-user mappings, such as those found in common office environments with fixed workstations, active WMI probing is not needed.  Roaming and other mobile clients can be easily identified even when moving between addresses by integrating User-ID using Syslog or the XML API, and can capture IP-user mappings from platforms other than Windows as well.  On sensitive and high security networks, WMI probing increases the overall attack surface, and administrators are recommended to disable WMI probing and instead rely upon User-ID mappings obtained from more isolated and trusted sources, such as domain controllers. If you are using the User-ID Agent to parse AD security event logs, syslog messages, or the XML API to obtain User-ID mappings, then WMI probing should be disabled.  Captive portal can be used as a fallback mechanism to re-authenticate users where security event log data may be stale.

 

If WMI probing is used, it should not be enabled on external untrusted interfaces, as this would cause WMI probes to be sent outside of your network that contain sensitive information such as the username, domain name, and password hash of the service account configured for use by the User-ID agent.  This information could potentially be exploited by an attacker that could then penetrate the network to gain further access.

 

.

 

Use a dedicated service account for User-ID services with the minimal permissions necessary

User-ID deployments can be hardened by only including the minimum set of permissions necessary for the service to function properly.  This includes DCOM Users, Event Log Readers, and Server Operators.  If the User-ID service account were to be compromised by an attacker, having administrative and other unnecessary privileges would expose the enterprise to additional risk of destruction or theft of sensitive data.  Domain Admin and Enterprise Admin rights are not required to read security event logs and consequently should not be granted.

 

.

 

Deny interactive logon for the User-ID service account

While the User-ID service account does require certain permissions in order to read and parse Active Directory security event logs, it does not require the ability to log on to servers or domain systems interactively.  This privilege can be restricted using Group Policies, or by using a Managed Service Account with User-ID (See Microsoft Technet for more information on configuring Group Policies and Managed Service Accounts.)  If the User-ID service account were to be compromised by a malicious user, the potential attack surface would be greatly reduced by denying interactive logon.

 

.

 

Deny remote access for the User-ID service account

Typically, service accounts should not be members of any security groups that are used to grant remote access. If the User-ID service account credentials were to be compromised, this would prevent the attacker from using the account to gain access to your network from the outside using a VPN.

 

.

 

Configure egress filtering on outbound internal traffic

Prevent any unwanted traffic (including potentially unwanted User-ID Agent traffic) from leaving your protected networks out to the Internet by implementing egress filtering on perimeter firewalls.  In sensitive environments, white listing trusted and business essential applications diminishes the possibility of allowing unwanted traffic, and also helps reduce possible vectors that could be used to exfiltrate data.

 

.

 

See Also

For more information on setting up and configuring User-ID see the following:

 

owner: ggarrison

Comments
by andrew.stanton
on ‎10-14-2014 01:02 PM

My only challenge to the best practice of "Only enable User-ID on trusted zones" is that it conflicts with recommendations/requirements for GlobalProtect.  See:

https://live.paloaltonetworks.com/servlet/JiveServlet/previewBody/2020-102-24-14175/GlobalProtect-Co...

page 27

"In order to identify users, “Enable User Identification’ must be checked on the zone where the tunnel interface is bound."

https://live.paloaltonetworks.com/docs/DOC-6586

page 9 (document), page 15 (PDF)

"Make sure to enable User-ID in the zone where the VPN tunnels terminate."

https://live.paloaltonetworks.com/docs/DOC-2163

"Normally, GlobalProtect traffic comes from the untrust zone (internet), so it is quite possible that the enable-user-identification flag is not turned on."

I think to some degree, there has always been confusion for me around which zone really needs User-ID enabled and why.  Is it supposed to be the tunnel interface zone or the zone of the interface that the tunnel interface is bound on?  Or is it supposed to be both?  Personally, it does not make sense to me that it is the zone of the interface that the tunnel interface is bound to for exactly the reasons stated here and the advisory just posted ( Customer advisory: Security Impact of User-ID Misconfiguration ), but we get warnings when we do commits if we do not enable this option on the bound interface zone.  I do not think we get warnings if we do not enable it on the tunnel interface zone.  Here is the warning you will see:

Warning: Zone 'Untrust' does not have 'enable-user-identification' turned on for globalprotect gateway 'MyGateway'

And here is an example configuration for this scenario (where we avoid this error by turning on user-identification on the Untrust zone:

set zone Untrust network layer3 ethernet1/2

set zone Untrust enable-user-identification yes

set zone Untrust user-acl include-list 192.168.255.0/24

set zone GP-VPN network layer3 tunnel

set zone GP-VPN enable-user-identification yes

set network tunnel global-protect-gateway MyGateway local-address interface ethernet1/2

set network tunnel global-protect-gateway MyGateway tunnel-interface tunnel

set network tunnel global-protect-gateway MyGateway client ip-pool 192.168.255.0/24

The only thing that has made me feel better about this is putting the ip-pool in the include-list, hoping that the firewall does not make any call outs to identify IP addresses on the Internet.  Although, to me since identification is based on the authentication happening through GP, I would not think that any additional identification mechanisms like probing would need to be enabled.  I think it would be beneficial to control the identification discovery mechanisms from the zone.

My 2 cents.

~ Andrew

by ggarrison
on ‎10-15-2014 09:31 AM

Andrew,

You raise a very good point regarding User-ID and GlobalProtect.  First, I'd like to clarify that the "tunnel interface zone" and "the zone that the tunnel interface is bound on" are the same thing, and is logically separate from the zone containing the GlobalProtect gateway interface.  User-ID must be enabled on the tunnel zone, because this is where GlobalProtect users will logically ingress the firewall after successfully authenticating to the gateway.  This distinction between the GlobalProtect gateway zone and the GlobalProtect tunnel zone is important.  From an administrative standpoint, tunnel zones are "trusted", as successful authentication is required prior to sending or receiving traffic, so enabling User-ID on these zones does not present any significant amount of risk.  In fact, many administrators place tunnel interfaces in their existing "trusted" zones in order to streamline administration and deployment of GlobalProtect.  Administrators wanting to apply more granular security controls to VPN users can create a separate VPN zone to build their policies.

In your example configuration, User-ID only needs to be enabled on the "GP-VPN" zone, and is not necessary on the "Untrust" zone.  This configuration will also stop the warnings from occurring at commit, without exposing User-ID services on any untrusted zones.

by wkey
on ‎10-16-2014 06:06 AM

Do you recommend restricting the amount of Domain Controllers the PA can talk to when configuring Agentless User-ID?

I have 6 domain controllers on my network and I'm not sure if the PA needs to talk to all of them.

Thanks!

by cpainchaud
on ‎10-16-2014 09:46 AM

It's a matter of CPU, number of DC is not really important it's how many requests/second they will have to handle and how much CPU of the firewall it's going to consume.

Peace of mind says : use an external agent.

Choice is open

by wkey
on ‎10-16-2014 09:54 AM

I'm not concern about CPU consumption, but more of security best practices in regards to User-ID polling and what this service account should access. Should one limit the scope to a subset of DCs or is the risk small enough not be overly concerned about?

What are the benefits for using all 6 DCs? If I limit the scope to 1 or 2, would I loose information that could be used for User-ID?

by cpainchaud
on ‎10-17-2014 10:46 AM

Users are spread over DCs (being physically on site A doesn't mean you will use site A DC). So if you want to catch all logons you need to monitor all DCs. You can use one or several agents to to monitor all your DCs.

by wkey
on ‎10-20-2014 05:14 AM

Makes sense! Thanks!

by andrew.stanton
on ‎10-21-2014 06:43 AM

I was going to ask you to update the existing documentation, but I see it was already done.  Thank you.

Also, I went back to try to find out why I got commit warnings advising me of needing User-ID on the globalprotect gateway interface.

Warning: Zone 'Untrust' does not have 'enable-user-identification' turned on for globalprotect gateway 'MyGateway'

I found it was because I had accidentally commited the gateway without a tunnel interface, so it was acting like an internal gateway and hence requested user-id on the gateway interface, but i had set it up on an external interface.  So, that is a legitimate scenario to request User-Id.


Thanks.

by geoa
on ‎02-18-2016 03:30 AM

Has anyone ever used managed service account with user-id?? 

by mart_e
‎03-10-2016 05:21 AM - edited ‎03-30-2016 01:23 AM

One remark regarding this: "Use a dedicated service account for User-ID services with the minimal permissions necessary". It is true that when you use agentless User-ID then this user explained here is sufficient https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-Agentless-User-ID/ta-p/...

 

But when you use also Client Probing then I read from PanOS 7.0.5-h2 help following: Client Probing tab > "Note: For WMI polling to work effectively, the User Mapping profile must be configured with a domain administrator account, and each probed client PC must have a remote administration exception configured in the Windows firewall. For NetBIOS probing to work effectively, each probed client PC must allow port 139 in the Windows firewall and must also have file and printer sharing services enabled."

So you actually have to use domain admin account if you want to take advantage of client probing with agentless User-ID. Is it true or am I missing something here?

If it is true then it should be mentioned in above article also. Of course other means explained above (User-ID enabled on trusted zones and usage of included/excluded networks) help to avoid exposure of domain admin info outside of your network. 

Remark on 30.03.2016 - I communicated with support and it turns out that domain admin account is not needed for probing and this info is misleading in PanOS 7.0.5-h2 help (so account specified in above link should be sufficient). I have not tested it myself yet, but consider it when you use client probing.

 

by CYonchev
on ‎08-27-2017 12:26 PM

FYI - If your service account is not member of Domain admin group - YOU WILL HAVE PROBLEMS with filtering access based on active directory secuiry group!!!!

That is confirmed 100% on 8.0.3-4 etc. learned the hardway along with support!

Ask Questions Get Answers Join the Live Community