Identity Collector - Microsoft AD syncronize Audit Events b/w DCs - truth or mispercention?

[Sergej_Gurenko]

This is a question for slightly older Member Exclusive Content > Enforcing Security Based on Identities: Slides, Video, and Q&A presentation. Unfortunately, the comment section there is closed, so I'm asking a question here, please see the question below:

#Question:

The presenter @Peter_Elmer and the host @PhoneBoy repeated that all the Domain Controllers (DCs) would replicate the User login events almost instantly. And this is the reason there will be duplicate information on the Identity Collectors... Is it really the case? Hope the answer will help to other admins as well.

#Detials:

It is stated twice during this great recorded session, first in minute 38 "Identity Sources: Identity Collector
Design guidelines and options" (page 34) and then presenter returns back to the same page on minute 55 during QnA to state:

All Logon Servers inside a ‘fully trusted’ domain are sharing login events

I lived up to this day thinking that Domain Controllers only synchronise Active Directory DB (e.g. users, passwords and GPO mostly). And Event Log (for the DC events such as login/logoff) is sitting locally on the DC server only. This is the reason all security monitoring tools for AD need to be installed on each DC. That is one can read the config from _any_ DC. But Security events are always _local_. Was I totally wrong?

#Potential explanation of DPD seeing event twice (even without DC replicating Audit Events):

I can see a change to cause a clash if ALL collectors monitor ALL DCs and then report to ALL PDPs. That is IdentityCollectoer1 and IdentityCollector2 each monitoring DC1 DC2 DC3 and DC4.

I also found something like "by default, security events are local" - this implies there is some non-default settings in AD. But I was not able to find anything related to such config.

#References:

One of many pages dated to 2005 (I hope not much changed in AD since then)  https://techgenix.com/ACommonMisconceptionRegardingSecurityLogs/

Domain controllers host Active Directory, which manages the security of your Windows-based networks. If you have several domain controllers in the same domain, Active Directory information is automatically replicated between them so that they all contain identical (except for replication delay) copies of Active Directory and therefore contain identical security information. But do they also contain identical copies of the Security log?

No. That’s a common misconception. Security logs are not replicated between domain controllers. To see why, remember that a user is always authenticated by some specific domain controller in a given situation, so if logon/logoff auditing is enabled on all domain controllers, a logon security event will only be logged to the actual domain controller that handles the authentication of the user.

So don’t assume AD replication means Security log replication!

Events we are discussing

Event ID Description

4624	An account was successfully logged on
4634	An account was logged off

Finally, the KB recommends totally different approach to what is recommended by Peter Elmer:

Identity Collector - Technical Overview - sk108235  Identity Collector Redundancy section:

Identity Collector currently does not offer an "out of the box" redundancy. However, the following configuration can offer this feature:

Install Identity Collector on two separate Windows server machines.

Configure both for query the same identity servers and gateways (all configuration is identical).

With this configuration, you will have "Active/Active" redundancy.

The domain controllers should not be dramatically affected by this change, as the API Identity Collector is using is light resource consumer. On the gateway side, only the first event will be processed (the second one will be ignored).

P.S. Finally, I'm aware that users are usually silently disconnecting from the network and no log-off events are available.

[PhoneBoy]

We’re actually reading the Security Logs, as stated in sk108235 and based on the fact it is a requirement to have this permission to run Identity Collector.
Also keep in mind this video is a couple years old and may not reflect the current advice.

It also doesn’t reflect R81.20, which improves pdpd in numerous ways.
One is with regards to (re)learning identities from other gateways after a failure.
You should need far less Identity Collectors also since capacity should be significantly improved.

[Sergej_Gurenko]

@PhoneBoy  greatly appreciates you answering this question (you have plenty of commitments - well done generating content for the community!)

Do you know the answer to my original question? It is mostly Microsoft AD rather than the Check Point question:

* Do all Logon Servers (e.g. Domain Controllers) inside a ‘fully trusted’ domain (e.g. Active Directory domain) share login events (e.g. Audit Event 4624). To simplify, let's talk about a single domain, no forest.

I think Peter's statement was misleading/confusing. Unless I misunderstood his message or Microsoft domain replication for the Audit Events. Here is page 34, which threw me off the tangent (the questionable statements in red frame):

[PhoneBoy]

Yeah, that is more of a Microsoft AD question and I’ll have to defer to someone else on that.
The actual audit event is less relevant to us since we only read the security logs (which don’t replicate).

[Peter_Elmer · Accepted solution]

Hello @Sergej_Gurenko ,

about "all logon servers inside a 'fully trusted' domain are sharing login events: 

It's a fact I have observed in the past and that was reported to me by Active Directory administrators. When I integrate in to Active Directory I ask the question: have you configured AD Logon servers to share login events? Most often the answer is 'yes'. The main focus of the webinar was to enable dialog between us - security focused engineers - and Microsoft Active Directory administrators. In this dialog I am asking for referencing Microsoft original documentation in case of doubt.

So far, Microsoft Active Directory Administrators have shared the way they configured their environment at a generic level. I shared guidelines how to configure ID sharing to achieve best security and we always found a solution for specific scenarios. Unfortunately each specific scenario is - specific. In a webinar I am challenged to formulate guidelines that meet a broader - more generic - group of solution scenarios, so I share what I have seen with the target to enable dialog between 'us' and 'them'. 

It is important to understand, that the webinar was given at the time we had R80.40 as recommended release and here we introduced Identity Conciliation. The slide following the one you quote indicates the use of Identity Broker to share Identity Sessions and to achieve resilience instead of 'cross connecting' both ID Collectors to both PDP instances. The webinar is focused to introduce ID Broker and ID Conciliation as by the time new capabilities allowing to scale identity based security. 

You may have seen sk179544 that reviews these concepts using R81.10 capabilities. Just like the webinar you are referencing,  sk179544 is about generic guidelines - information that shall enable dialog with 'experts from the other side' in order to find a common understanding and a solution for achieving the best security. 

best regards

pelmer