Question about Identity Awareness

[RemoteUser]

Hi Mates,
I have a question about Identity Awarness. 

If a cluster is configured in my environment that only acts as identity awareness, does this mean that both nodes act as publishers and subscribers, or does only one act as a publisher and the other as a subscriber, and/or do the roles reverse during a failover? I hope I have explained myself clearly and understood the concept correctly.

Thanks

[Vincent_Bacher]

More details please. As I usually use the words publisher and subscriber for identity broker: are you talking about identity broker setup?

In general only the active node of the cluster is handling the sessions when we are talking about pdpd. When it comes to enforcing firewalls, meaning pepd, Sessions are synced.

[RemoteUser]

Hi Vincent, yes i talking about identity broker setup - HA setup. 

[Vincent_Bacher]

Then only on master you see publishers and subscribers when eg issuing comman „pdp b s“ and this is how it is supposed to be. Same applies to propagated sessions.

[RemoteUser]

And if I run pdp connections pep on the Master Gateway, am I seeing the gateway (or cluster) that forwards the identity information to the Identity Broker (master)? Is that correct?

[Vincent_Bacher]

pdp connections pep only shows connections to the enforcing firewalls (PEPs). It does not show which gateway or cluster node is forwarding identity information to the Identity Broker. To see PDP ↔ PDP / Broker connections, you would use pdp connections b s. Adding -e shows last connection error info.

[RemoteUser]

So, if I enable a gateway with AI (Gateway A) and configure a Cluster Identity Broker (Cluster B), then run pdp connections pep, I should only see Gateway A in the output. Is that correct?

[Vincent_Bacher]

Actually, it looks like there’s some confusion here. Let me clarify:

• PEP (Policy Enforcement Point) = the gateways/firewalls that enforce policies. These are what pdp connections pep shows.
• PDP (Policy Decision Point) = the component that decides policies, usually running on Identity Awareness gateways.
• Identity Broker Cluster = just handles identity distribution between PDPs; it is not enforcing anything.

So in your scenario:

• Gateway A is a PEP → appears in pdp connections pep.
• Cluster B is an Identity Broker → does not appear in pdp connections pep.
• To see connections between PDPs/Brokers, you would run pdp connections b s.

Think of it as: PEPs enforce, Brokers distribute, and pdp connections pep only lists the enforcers.

[RemoteUser]

Ok wonderful thank you for the explenation

[RemoteUser]

Hi Vincent, a question came to my mind last night before falling asleep 🙂
How do Identity Brokers communicate with each other if they are hosted on different management servers, for example in a large environment?

[Vincent_Bacher]

That should work without any problems. We, for example, have multi-domain management and therefore need domain layer PDP devices in every CMA to propagate the sessions from core layer PDP devices. The domain layer PDPs then propagate session information via identity sharing to the enforcing gateways (pep).

The communication relationships are configured in identity_broker. C, and to ensure that the whole thing is connected, firewall rules are of course also required for the devices involved. The punlishers connect to the subscribers via an SSL channel, for which a certificate is also defined in the gateway object, identity awareness section.

This should also work in your case with devices on different management servers.

fyi: As far as I know, Checkpoint has announced a significant change for R 82.10 or something? I still need to look at the details. This could simplify the whole thing significantly.

hope that helps 

P.S.: One small correction. The brokers are not hosted on the management server. They run locally on the gateway, and identity_broker.C is also located on the gateway.
The gateway object is managed as usual on the management server or the CMA. As mentioned above, the broker certificate is also managed here. You can import certificates that you have created yourself or purchased, although you do not need purchased certificates in the case of broker.

[RemoteUser]

Thank you very much, Vincnet. As I thought, communication is taking off thanks to identity_broker. C.

[RemoteUser]

Sorry Vincent, I have another question.

I’m seeing an issue in my environment where identity sharing appears to be disconnected. Yesterday, while reviewing the Administration Guide, I noticed the following:

• If the PDP or PEP is a cluster (and in my case the Identity Broker is a cluster), all members open the outgoing connection, but only the active cluster member accepts incoming connections. The cluster uses its Virtual IP address (VIP) for these connections.

However, in this CMA we are using gateways hosted in cloud like azure aws alibaba ecc, and those gateway does not have a VIP configured.
Could this be the reason why we are seeing identity sharing as disconnected, or am I misunderstanding something?

[Vincent_Bacher]

To be honest, I am not familiar with cloud-based devices in this regard.
But perhaps the following will help:
For reliability, we have set the sharing method to push everywhere, not smartpull.

The difference between these two modes is documented in sk149255.

to modify the method setting:

guidbedit -> GuiDBedit: Table -> Network Objects -> network_objects -> FirewallWithPEPD -> identity_aware_blade -> publish_method: push. Save the changes and perform a policy installation on all firewalls that you have changed AND on the firewall running pdpd. Be aware that policy push might flush identity awareness tables so maybe out of business hours. Tables will re filled automatically.

Not sure if that helps on your environment but worth a try.

p.s.: I must admit that I don't even know off the top of my head how it should look with normal clusters, because we almost exclusively use VSX, and there the connection is only established to the VS anyway. I would have to look for clusters without VSX at our company, but I am currently on sick leave.

[RemoteUser]

Thanks Vincent, it looks like sk149255 has been deleted.

[the_rock]

Seems like it brother. I cant find it by search either.

 

[Vincent_Bacher]

So sorry. Will have to research.

[Vincent_Bacher]

Unfortunately, I can't find any information about this.

[Vincent_Bacher]

And please be aware that the $FWDIR/conf/identity_broker.C file where publishers and subscribers are defined have to be identical on master and slave. If not or the file is not present at all on ha failover the broker connections won’t come up or not all of them. And all modifications require policy push to take effect.

[RemoteUser]

yeah sure thank you vincent!

[the_rock]

Thats the right file, yes.

[Vincent_Bacher]

I know. I've worked on it countless times, and we were the first to use the broker function. 😉

[the_rock]

Now I know Vincer is the guy to ask if this ever comes up again 😉

[Vincent_Bacher]

No problem, I have worked with the broker extensively as I am responsible for the broker environment at our company.

[the_rock]

I will definitely keep that in mind if I see this issue.