- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
02-19-2018 07:05 AM
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
02-19-2018 09:59 AM
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....
02-19-2018 07:37 AM
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.
02-19-2018 08:23 AM
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
02-19-2018 09:43 AM
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.
02-19-2018 09:55 AM
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.......
02-19-2018 09:55 AM
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.
02-19-2018 09:59 AM
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....
02-19-2018 10:00 AM
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.
02-20-2018 07:06 AM
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.
02-26-2018 11:33 AM
So far so good with 240 minutes. It has only been a few days, but no complaints yet.
Thanks!
02-26-2018 12:29 PM
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.
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!