- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
02-20-2019 12:13 AM
Hi
What I have
850
2x 5220's active / passive cluster
panorama
3 MS AD's + 2 Exchange boxes
I have the panorama userid sync with 850 and a VIP address on the 5220's so it always connected to the active node.
I believ that panorama pulls userid info from each node and sends it to each node - I believe I believe I tested that before.
My PA's 850 & 5220's have the MS AD user id configured so that they scan the security log on my MS AD boxes - but I have the values set rather low - I want responsiveness to changed conditions. Note I also try and install GP on all user machines (laptops and PC), but not on servers
What I noticed recently was my cpu load on my MS AD boxes was massive on all 3, because I had expanded my security event log to 2G (maybe 20G) and it was taking too long to scan the logs - in fact the next scan started before the first had finished.
Why isn't the scan more intelligent - why can't it scan from where it last left. My short term attack on this is I dumped my security event log
Also i had each PA talking to each MS AD !
My plan is to reduce the connetions so 1 MS AD per PA and also maybe increase the wait time between each scan.
OR I could install the agent on each MS AD.
I think I would rather rely upon GP - because I like how it changes users based on who is logged in currently on Windows - the active user ...
Also I notice there is a new feature in 9.x using some new function to do the scanning less intrusive.
So what the forums thoughts. from memory the best practise out of the PA doco is to use the inbuilt client on the PA's
THanks
A
Note I tried my SE - but i could possibilty wait till xmas and not hear anything back from him
02-22-2019 03:05 AM
I think its not the size but the fact I have 3 PA's talking to all the MS AD's and scanning every 15 sec. I believe they over lap . I am in the process of detuning and if that doesn't work I will look again at the agent - I had that initially installed but removed it I believe after reading about best to use the inbuilt agent, so i move to that !
Hence the proposal to run/try/consider agents; the the agents will do the work once and the firewalls just need to pick up the digest (agents actually send out updates to the firewall, firewall only queries the agent when they see an unknown IP and that's where probing could help pick up stragglers)
in regards to probes vs GP, there's no 'better' between the two, they overlap and augment, and some may work better in one environment than the other. using both covers all the gaps, if one is undesirable the other can pick up the slack
02-20-2019 01:50 AM
i'd recommend running an agent on your ADs (one on each) as the agents will actually scan logs a little more intelligently
The agents should also be able to detect who's logged on either by fetching the logon events the moment a different user logs on, or as a secondary by probing the clients regularly, adding GP will help catch any strays or unscannables and help tighten the gap in case of any latency or other issues that may delay detection
02-21-2019 02:12 PM - edited 02-21-2019 03:22 PM
So probing is better than GP Client on the PC
This is what I got from the 8.1 doco
User-ID provides many methods for safely collecting user mapping information. Some legacy features, which were designed for environments that only required mapping of users on Windows desktops attached to the local network, require privileged service accounts. If the privileged service account is compromised, this would open your network to attack. As a best practice, avoid using legacy features such as client probing, NTLM authentication, and session monitoring that require privileges that would pose a threat if compromised. The following workflow details all required privileges and provides guidance for the User-ID features which require privileges that could pose a threat so that you can decide how to best identify users without compromising your overall security posture.
Sounds like they are suggesting to not use probing
More of my question might be better put as
should I do
5220 -> to 1 MS AD or maybe 2 MS AD
850 -> to another AD
I don't need to fully mesh it.
or if I want to fully mesh it then I should probably use the agent ..
02-21-2019 03:30 PM
I'm having trouble understanding why you want 20 GB of logs on your DCs. I can't imagine you're using the Windows Event Viewer with its limitations, so I would guess you're using powershell or similar to run queries, which further would reduce the need to have them local.
Why are you handling log retention that large on a system that's operating as your domain controller? Those should be offloaded to a dedicated log server if you want to keep that many logs.
Given that you seem to stick to vendor best practices, what does Microsoft say as their recommendation for log retention directly on the DC given your user and group sizes?
02-21-2019 03:48 PM - edited 02-21-2019 03:50 PM
Wow, thats a bit hostile.
So I would like to have more than 1 days worth of security events.
20G is not that big.
Yes long term plan is to ship them off.
I found this old recommendation for 2008
https://support.microsoft.com/en-ca/help/957662/recommended-settings-for-event-log-sizes-in-windows
they are talking max 16G for 2008
But thats not really the point, I might have auditing turned on and produce a lot of audit events. Thats my requirement
* I am rather dissapointed that the agent can't keep track of were in the event log it last looked - and maybe the agent does that whilst the remote agent on the PA does.
* I did configure a rather low amount of sleep time between retry/reread.
As for following best practise .. well my SE keeps pounding in use PA best practise - so I am following PA advise. I was questioning why use the agent with probing - when PA highlights that it best not to. Maybe there is something missing from the doco.
Atleast to me is seems more sensible to use the GP data from the device to say who is logged on - it does seem to do a desent job.
02-21-2019 04:09 PM
> Wow, thats a bit hostile.
Sorry about that, it wasn't my intent. I was trying to determine if the change you made was something you got the ok with from Microsoft.
My point is that you've increased the logging retention, are using a product that reads logs by design, and works fine when you delete the logs that are only there because you've increased the retention value.
Once the firewall/agent completes the initial scan, it actually does start only where it left off. It has to succeed once though, so the logs you have might actually be ok.
Try bumping the retry/reread value considerably for the first run. Once it completes, then you could probably lower that value to get faster responses to log changes.
02-21-2019 04:15 PM
Okay
So by example at work we generate logs of 800M-1.2G in size daily and we use a nice open source program called filebeats it works well.
I think its not the size but the fact I have 3 PA's talking to all the MS AD's and scanning every 15 sec. I believe they over lap . I am in the process of detuning and if that doesn't work I will look again at the agent - I had that initially installed but removed it I believe after reading about best to use the inbuilt agent, so i move to that !
We live we learn ...
A
02-22-2019 03:05 AM
I think its not the size but the fact I have 3 PA's talking to all the MS AD's and scanning every 15 sec. I believe they over lap . I am in the process of detuning and if that doesn't work I will look again at the agent - I had that initially installed but removed it I believe after reading about best to use the inbuilt agent, so i move to that !
Hence the proposal to run/try/consider agents; the the agents will do the work once and the firewalls just need to pick up the digest (agents actually send out updates to the firewall, firewall only queries the agent when they see an unknown IP and that's where probing could help pick up stragglers)
in regards to probes vs GP, there's no 'better' between the two, they overlap and augment, and some may work better in one environment than the other. using both covers all the gaps, if one is undesirable the other can pick up the slack
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!