Agentless or User-ID Agent?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Agentless or User-ID Agent?

L1 Bithead

Hi,

In my environment, we have several domain controllers around the world across MPLS. In order for users to go out to the internet, they must have an AD account in a certain AD group. This seems to work just fine....but recently we've had a few issues where the user will lose connection to the internet. When we look in the logs, the user's User ID is no longer sent. About 5-10 minutes later all is back to normal. We have about 15 domain controllers under User Mapping > Server Monitoring. I have a feeling one of them has some issue.

Either way, what is the typical recommendation others have....does the Agentless work better in multi-domain controller environments across the world or does a User-ID Agent make better sense. According to Palo....User-ID Agent is the recommendation.

 

D

1 accepted solution

Accepted Solutions

45 mins.... wouldn't work for me as most users have very little domain activity once logged in.

 

Give it a go at 240 mins. (I think thats 4 hours)... bit late in the day....

View solution in original post

10 REPLIES 10

Cyber Elite
Cyber Elite

@david.alicea,

In that type of enviroment I would highly suggest following the recommendation to use User-ID Agents instead of using the Agentless method. You might want to take a look at this LINK to get some ideas on what the actual recommendations are and fit it appropriately to your enviroment. 

L7 Applicator

yes for sure, as @BPry suggested. User-ID agents would be best in your enviroment but not sure if this would resolve your suspected server issue...

 

This may just be an issue with your "user identification timeout" setting.

 

what is this currently set to...   we use 24 hours but others that have previously posted prefer 4 to 8 hours

As @Mick_Ball suggested the actual method you use does not seem to change something with your issue. The must be something wrong on one of these servers or with the configured timeout.

 

But regarding the actual topics question: ( @BPry@Mick_Ball please correct me if I am totally wrong here) In this case (highly distributed single forest domain) I would also prefer to use the agentless method because of low complexity (at least no added complexity with the log forwarding from DC to log server where the UIA reads the logs) and also because of low bandwith consumption over the MPLS links because the firewall only reads the required log events (compared to having the UIA connecting directly to all DC where it must parse the whole security log and not just the required events). Depending on the actual amount of users, whitch has an impact on the mgmt CPU, I would stay with the agentless solution. And as it is already set up I assume there aren't any problems with high mgmt CPU utilization.

Hi, @Remo, noted...   Good post...

 

for me it's an eva iva choice, difficult as not knowing the full picture.

 

My assumption was based on a UID agent at each domain location, I would therefore assume only updates were sent from the agent to the PA.

 

I must admit I do not know the full ins and outs of agents but I based my current setup on what was best for me going by the PAN docs.

 

Thanks for the detailed post, very helpful...

 

on that note,,, can I just say that I quite enjoy having the agents, autodiscover works well and liking the search option in the GUI. not everyones cup of tea.......

 

It seems that a few years back, the configuration/setup for User-ID agents was a bit "flaky". This is why the administrators back then decided to switch to agentless. It appears that agentless has been running just fine for 2+ years. As @BPry mentioned...this is the recommendation from Palo to have User-ID agent running. We might look into that again, but the setup itself and logistics will take a bit to go through. @Mick_Ball mentioned the User Identification Timeout...mine is 45 minutes.

 

Yeah, the servers around the world seem to be fine, when it comes to CPU. One thing I might do is the Palo units are sitting in the US (where the egress to the internet is for all users around the world, for now). I might just exclude most of the other servers and limit them to the US DCs only, where the Palos reside.

45 mins.... wouldn't work for me as most users have very little domain activity once logged in.

 

Give it a go at 240 mins. (I think thats 4 hours)... bit late in the day....

@david.alicea,

That's a good point, and I likely would have followed the same deployment method as you did a few years ago because of the issues I was having with the User-ID agents back then. I can safetly say however that the User-ID agents have gotten a heck of a lot better and more stable in that time. 

Depending on your actual enviroment and what exactly you are montioring 45 minutes for a timeout value is pretty low. Unless you have a lot of shared user locations, I would highly recommend bumping that up a little bit and seeing if that doesn't solve your issue. You could have your User-ID mapping aging out, which would definetly cause the issue you are describing. 

Thanks everyone. I'll be upping the value from 45 minutes to 240 tomorrow afternoon. I will also be removing a few of the DCs in the list.

Eventually we will look at User-ID Agent, but we want to see if this helps for now. I'll let everyone know.

So far so good with 240 minutes. It has only been a few days, but no complaints yet.

 

Thanks!

Nice one @david.alicea.

 

Thanks for the update...

 

for me... 4 hours is a minimum, my dhcp is 7 days for over 8k users and 24 hour timeout works fine.

 

everybodys setup is different but if 4 hours works for you then stick with it...

 

mick.

  • 1 accepted solution
  • 6581 Views
  • 10 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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 LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!