User-id and 8.1.x and MS AD best practise

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

User-id and 8.1.x and MS AD best practise

L4 Transporter

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

 

 

 

 

1 accepted solution

Accepted Solutions


 

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

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

View solution in original post

7 REPLIES 7

Cyber Elite
Cyber Elite

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

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

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 ..

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?

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.

 

 

 

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.

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


 

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

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization
  • 1 accepted solution
  • 4624 Views
  • 7 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!