Palo Alto – User-ID Agentless and AD Integration

WINDOWS EVENT IDs USED

Windows Logs > Security:

4624 – Logon Success
4768 – Authentication Ticket Granted
4769 – Service Ticket Granted
4770 – Ticket Granted Renewed

 

CAN I FORCE AN UPDATE TO PROPAGATE THE USER-ID MAPPING

There is no built-in Windows command to directly force an update of the User-ID mappings on a Palo Alto Networks firewall. The User-ID technology primarily works by monitoring the Windows Security Event Logs to detect logon and logoff events, and it updates the User-ID mappings accordingly.

That said, if you want to “force” an update from the Windows side, you could manually trigger an event that would generate a new logon event. One way to do this is by re-authenticating a user. For example, you could lock and then unlock a Windows workstation, log off and then log back on, or disconnect and reconnect a VPN session.

These actions should generate new Event ID 4624 logon events in the Security Event Log, which the User-ID agent should detect and use to update the User-ID mappings. However, there might be a slight delay before the mappings are updated, depending on how frequently the User-ID agent is polling the Security Event Log.

Keep in mind that it’s generally not necessary or recommended to force User-ID updates in this manner. The User-ID technology is designed to automatically track user logon and logoff events in real time, ensuring that the User-ID mappings are kept as current and accurate as possible.

Lock and Unlock Device:
While in your Remote Desktop session, simultaneously press the “CTRL + ALT + END” keys on your keyboard.

 

ORDER OF AD SERVERS

In the context of a Palo Alto Networks firewall, when there’s a list of servers configured for the User-ID agent to monitor (like Active Directory servers), the firewall processes them in the order in which they are listed.

If the first server in the list is available, the firewall will connect to it and begin pulling User-ID information. If that server becomes unreachable, the firewall will attempt to connect to the next server in the list, and so forth. This process is done to provide redundancy and ensure that the firewall can continue to pull User-ID information even if one or more servers become unreachable.

However, starting from PAN-OS 9.0, there’s a feature called “Distribution of User-ID information collection” which allows User-ID to distribute the load of information collection across all available servers instead of the traditional sequential method.

Remember, it’s always a good idea to refer to the official Palo Alto Networks documentation or your firewall’s online help for the most accurate and up-to-date information, as capabilities can change between different versions of the firewall software.

 

ZONES AND ENABLING USER-ID

The “Enable User Identification” option in the Zone settings of a Palo Alto Networks firewall is used to enable or disable the use of User-ID for that specific zone.

When you check (enable) this option, the firewall will apply User-ID technology to track and control traffic based on users and user groups, not just IP addresses, for that zone. This means that the firewall will use its User-ID mappings (associations between usernames and IP addresses) when processing traffic entering or leaving that zone.

Conversely, when this option is unchecked (disabled), the firewall will not apply User-ID for that zone. In this case, the firewall will not use usernames or user groups when processing traffic for that zone, and will instead handle traffic solely based on IP addresses and other non-user criteria.

Enabling User-ID on a zone can be very beneficial for enforcing user-based security policies. For example, you could create a policy that allows certain users to access specific resources, while blocking others, and this policy would be enforced on any traffic entering or leaving any zone with User-ID enabled.

 

WHAT IF I DON’T HAVE “ENABLE USER IDENTIFICATION” CHECKED BUT HAVE AD GROUPS CONFIGURED

If the “Enable User Identification” option is not checked in the Zone settings of a Palo Alto Networks firewall, User-ID will be effectively disabled for that zone. As a result, the firewall will not consider usernames or user groups when processing traffic for that zone.

If you have created security policies based on Active Directory (AD) user groups, and User Identification is not enabled for a given zone, those policies will not function as expected for traffic entering or leaving that zone. Without User Identification enabled, the firewall will not associate incoming or outgoing traffic with specific users or user groups, which means it won’t be able to apply user-group-based policies to that traffic.

For user-based policy enforcement to work, User Identification must be enabled for the zones where you want these policies to apply. If it’s not enabled, the firewall will handle traffic based solely on IP addresses and other non-user criteria, even if you have specified user or user group conditions in your security policies.

Please always refer to the official Palo Alto Networks documentation or your firewall’s online help for the most accurate and up-to-date information.

WINDOWS SIDE TROUBLESHOOTING

In a Windows Active Directory environment, you can use the `nltest` command-line utility to find out which domain controller authenticated the last logon request. The `nltest` utility provides information about the state of a computer’s secure channel to a domain controller.

Here’s how to use it:

1. Open the Command Prompt or PowerShell as an administrator.
2. Run the following command:

nltest /dsgetdc:{your-domain}

Replace `{your-domain}` with the name of your domain.

The output of this command will provide information about the domain controller that the computer is currently connected to. This is likely the domain controller that authenticated the most recent logon request, though this isn’t always guaranteed to be the case due to the complexities of how Windows chooses domain controllers for authentication.

In the case of Event ID 4624, which logs successful logon events, it should include details about the domain controller that authenticated the logon request. You can check the security event logs on the domain controllers themselves, as mentioned in the previous response.

Remember to check the official Microsoft documentation or your system’s help files for the most accurate and up-to-date information, as the exact process may vary depending on your environment and the version of Windows you’re using.