AzureAD Identity Awareness on VSX - sk179788

[VSX_Bernie]

Hi all,

I wonder if anyone else has experienced this.
We have been setting up AzureAD for Access Roles in Identity Awareness, for Virtual Systems on VSX clusters.

We have been following this SK with great success - sk179788:
Access Roles with groups/users from Azure AD object are not enforced when using Remote Access VPN wi...

When we did this today, we managed to break another Virtual System's Identity Awareness.
We quickly found out that that when we modified the Realms file of one VS:
$CPDIR/conf/DataCenterServicesRealms.conf

This propagated to the realms file of ALL other Virtual Systems.

Example:
1. We added a line to the realms file of VS ID 11:
/opt/CPshrd-R81.10/CTX/CTX00011/conf/DataCenterServicesRealms.conf
2. This line is then also added to the realms file of VS ID 14:
/opt/CPshrd-R81.10/CTX/CTX00014/conf/DataCenterServicesRealms.conf

Anyone else ever seen this?

From our experience files in $CPDIR and $FWDIR for each Virtual System context is unique to the specific VS.

We run R81.10, with JHF 139 on GWs and JHF 156 on MDS.
GWs are OpenServer.

[Chris_Atkinson]

Please validate you command history and then consult TAC regarding the process for VSX.

[VSX_Bernie]

Hello Chris,

Thank you for the reply.
Command history is validated - we can reproduce this at will across several VSX clusters.

We have some clusters where AzureAD is not configured for Identity Awareness for any VS, so we can test editing of the file without interrupting production - making it quite easy to reproduce the behaviour.

Have created a case for TAC - currently awaiting their reply.

I was just interested to hear if anyone else in the community had experienced this before.

[Jan_Kleinhans · Accepted solution]

Hello,

it is a symbolic link:

lrwxrwxrwx 1 admin root 43 Aug 16 11:25 DataCenterServicesRealms.conf -> ../.. /../conf/DataCenterServicesRealms.conf

So if yo want different configuration you will have to remove the symbolic link and create a new file for every VS,

It's the same if you want to have different trac_client_1.ttm for different VS.

Jan

[VSX_Bernie]

Hello Jan,

Thank you for the clarification - it is much appreciated.
Then the product is really working as by-design.

Is this the recommended way (from Check Point) to configure SAML realms with different names, for separate VS?
I mean - there must be a reason why the default configuration is a symbolic link on VSX GWs - right?

Is the explanation simply that R&D has not accounted for this on VSX GWs?

I am just spit-balling here, but what if you added multiple "vpn_<NAME OF SAML REALM>" lines to the DataCenterServicesRealms.conf file?

Would PEP (or whatever engine checks the file) loop through all "vpn_" lines until it found a match, or would it settle for the first line of "vpn_" whether or not it is a match with the name of the Identity Provider configured in SmartConsole?

I am just wondering, because it seems to be counter-intuitive, that it would be a symbolic link on VSX GWs.

[Jan_Kleinhans]

Hello Bernie,

we are not using SAML at the moment, so I cannot help with this question. Maybe @Chris_Atkinson can help.
My knowledge of the symbolic links was from the trac file. So I think it maybe the same with the DataCenterServicesRealms.conf file.
I hope that in R82 the configuration of the VS will realy be independent from each other. Sometimes you think you changed something only for one VS but as it is only a link you change it for all VS.

My advisory is to look always for linking before changing a file.
I had these also some time ago with identity portal if I remember correctly.

[VSX_Bernie]

Hello Jan,

Message well received and understood.
Will keep out for the linking in the future.

I have asked TAC what the recommended way to do this is - will just have to wait it out for their answer.

[Chris_Atkinson]

As above please consult with TAC on the supported procedure and copy your SE as needed

[VSX_Bernie]

Hello Chris,

Thank you - I already did and am awaiting TAC.
I just find that it is often worth to post and share in the community as well, because often others have faced the same issues.

[Chris_Atkinson]

Absolutely I would likely do the same if I was in your position 🙂

[VSX_Bernie]

So - just spoke to TAC.
There is actually no internal documentation on the recommended way to do this in VSX - so no wonder I was unable to find anything.

They theorize that adding more realms to the file will be the best solution, but they will clarify with R&D and revert.
Will let you all know once I know more.

[VSX_Bernie]

So - R&D reverted, and they confirmed that adding more realms to the file is a viable solution.
I have asked them to clarify if this is the Check Point recommended way to configure it for VSX.

[VSX_Bernie]

Final reply from R&D is that there is no Check Point recommended way to do this on VSX.
Both solutions of adding more SAML realms to the file, and deleting the symbolic link are reported as viable from R&D.

I think we will try with adding more SAML realms to the file.
I fear that deletion of symbolic link and creation of static files may get overridden by JHFs, or at least in the event of a major upgrade.