Agentless vs Agent based User-ID

[Farzana]

Hello,

We have 500 users on site and currently using Agentless User-ID with PANOS 7.1.7

We are thinking of scaling up to Agent based. 

Can someone please guide me to a link/article that discusses the Pros and Cons of both? 

What are the common issues one facing with Agent based? Are there any limitations? etc.

Thanks in advance!

[OtakarKlier]

Hello,

I cant recall a pro vs con page that goes into this. Its one of those 'its your preference' things. With using agents all you are doing is offloading that aspect of the firewall to a server so you can free up some resources on the firewall, not many. We did it because we have the firewall emailing us of any high or critical events and we got spammed due to the failures, it was a WMI collision and we tried increasing resources and couldnt find a solution. Otherwise they were working the same, e.g. identifying users, etc.

Regards,

[BPry]

@Farzana,

Biggest thing is going to be that with the agentless method the constant log queries on the domain controller can be resource intensive for those servers, the resources required by the firewall to monitor the logs are actually pretty low. That being said @OtakarKlier is correct, it's really a personal preference thing. 

[Brandon_Wertz]

In an agent based user-id deployment the UIA queries the defined DC and collects all the logs which are new since the last update interval and discards  all but the required event IDs for user-ID mappings.

In an agentless deployment the firewall only collects the necessary event IDs for user-ID mapping.

I also thought there was some increased capabilities with syslog collection functionality (I can be wrong here.)

I'm also not sure about agent-less' ability to employ credential guard protections.  Which IMO is a requirement for deployment for anyone with a Palo firewall.  Granted getting it deployed is a PITA and extremely quirky.

If I had my choice I'd go with an agent based deployment. 

[BPry]

@Brandon_Wertz,

I don't think that you actually have any limitations with the syslog collection when using the agentless; it is a tad bit harder generally to verify everything is working however. 

I believe that the only time that you actually need to utilize the User-Agent is if you decide to use the domain credential method. This would require that you are actually using the agent instead of agentless; as the agentless method can't validate whether a valid password was being used. 

I'm personally not really a fan of domain credential filter as it would only detect when a user is submitting both a valid username and password and that the user logged into the source-ip matches those credentials. My thought process on this method is that I would rather know if any valid user-id is being submitted, regardless if the password is valid or if it matches the mapped source-user. 

[Brandon_Wertz]

---

@BPry wrote:

@Brandon_Wertz,

I'm personally not really a fan of domain credential filter as it would only detect when a user is submitting both a valid username and password and that the user logged into the source-ip matches those credentials. My thought process on this method is that I would rather know if any valid user-id is being submitted, regardless if the password is valid or if it matches the mapped source-user. 

---

You can do either type deployment...The more broad deployment will block known IP to known user ID without regard for a valid password.

The reason for not blocking this is you can't necessarily control if a user, however stupidly, decides to user their domain user ID for some Internet based hosted service.  At my company a lot of people user this ID for company driven cloud/Internet based services.  (We're in the process of whitelisting these sites.)

I actually like the "domain credential filter" because it's less intrusive and is more specific to what we're trying to block.  However the idiocrincies to get this to work makes it really difficult to get deployed.