I have the agentless user-id configured in my PA-500, software is 5.0.4. If I do a "show user ip-user-mapping all", it retrieves a list of usernames. However, in my traffic logs (which is currently only limited to a few machines that are running through it), there is almost no log entries with a source user listed.
Further explanation: ISP #2 is in an untrust zone, with no User-ID enabled on the zone. The MPLS private connection to the second site goes through that ISP, and that zone. Is there a way to make the users show in the logs for that subnet across the MPLS connection? Do I have to separate zones somehow?
And for my own PC, I'm still not sure why it doesn't show. I'm going from LAN to LAN in the logs and the LAN zone has User-ID enabled with the LAN subnet on the allowed list.
Is there a Domain controller at that remote side that you could put either the Agent on, or point your FW to that remote DC. User ID will only occur on the zone that the incoming traffic is seen at. If this is your Untrust zone, you would need to enable that (I doubt you would you enable it, but my point is... that is what you would need) So I am back at asking if DC services are at the remote location. You could also query the CAS server (from Outlook) if you feel your users could be identified this way. You can create a Captive Portal and a rule to get users to authenticate via Radius or web form. As for your PC. If you are plugging directly into the Mgmt interface, then this would explain why your PC is not being seen. I do not think you can enable UserID on the admin port, only one of the ethernet (copper) ports (eth1/1 to eth1/8) Let me know if I can assist with anything else.
There is no DC in the remote site...it's a small site and the MPLS private connection just allows them to connect to all of our internals AD-wise.
For my PC, I'm not physically plugging directly into the Mgmt interface, I'm simply logging into the firewall through the web.
A DC shouldnt be needed at remotesite for the userid to function.
The question here might instead be if the ip address the client at remote site uses is the same ip as your PA device will see (that is no NATs on the road)?
Because what happens with userid is that the PAN-agent will tail the security log of the DC-servers and trigger on these EventIDs:
Windows 2003 DC:
- 672 (Authentication Ticket Granted, which occurs on the logon moment)
- 673 (Service Ticket Granted)
- 674 (Ticket Granted Renewed which may happen several times during the logon session)
Windows 2008 DCs:
- 4768 (Authentication Ticket Granted)
- 4769 (Service Ticket Granted)
- 4770 (Ticket Granted Renewed)
and by that create a userid <-> ipaddress mapping database.
When you enable the userid feature of the interfaces facing the clients in your PA the PA will use this userid <-> ipaddress database to find out which userid is currently using which ipaddress.
The IP subnet in the remote site is 22.214.171.124/24. The IP of a client PC there, for instance, is 126.96.36.199. I'm sure there is NATing through the MPLS connection, but the PA in the traffic log shows the source address being 188.8.131.52.
I can check to verify that there is an entry in the DC's security logs for this client, but I also know that it's not showing a source user for any computer there (there are more than one PC there set up to go through the PA). We have Windows 2012 DC's, is there any difference in the Agentless setup between Windows 2008 DC's and Windows 2012 DC's for the security logs it tails?
I obviously wouldn't enable User-ID on that untrusted "ISP#2" zone that those clients MPLS through, so I guess I have to revert to something else for them. And as for my PC, I'll try delving through those DC logs as well.
I tested through VPN on my iPhone, and that source user shows up in the logs. I noticed that for my computer, I got some sporadic ones where it shows "domain\administrator" as a source user doing a ping. It then dawned on me that those entries are from Spiceworks on my PC checking the network with the domain admin account. I also wasn't directing my own PC through the PA, which threw me off when seeing the "domain\administrator" entries from my IP address (still kind of does, becuase the traffic was being logged even though my PC wasn't going through the PA as a gateway). I directed my PC through the gateway, and then browsed the web, and my source user entry shows up fine.
Just have to figure out the easiest way to get the remote subnet working without putting User-ID on the untrust ISP#2 zone.
If your 2nd ISP is simply a PtP connection across the MPLS link, to connect your remote network to your HQ location, then you could enable UserID. What other (non-MPLS network) traffic is seen on ISP#2
That's what my whole conundrum is about...ISP #2 is a secondary ISP, configured to be a failover if ISP #1 goes down, but can also be used for Internet access by the main site. The P-2-P across the MPLS is configured through that ISP #2 circuit, so I have both types of traffic (private and public) going on it.
So the users that are at the remote location, do they authenticate to a DC on the firewall site? If so, then is the firewall picking up these logon events from this local DC?
Does this traffic then appear to be coming into the firewall from the local DC side or from the Untrust private MPLS side?
I think the key is to understand that packet flow and what is expected - what ISP/ interfaces do you expect to receive and transmit on.
As long as you have the correct mapping and are seeing traffic traverse the firewall (like a u Turn of some sort) the entries should be in the firewall log traffic logs.
----DC----Trust----|PAN FW|/// ISP 2----------------Internet
SO far if the remote users are coming in from ISP 1 and being routed to the DC on the trust side, is there a route saying that traffic must then exit out ISP 2?
If so, perhaps the routing and zone security policies need some addressing.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!
The Live Community thanks you for your participation!