SAML authentication stops working after FW Upgrade / Fresh Install

[Thomas_Eichelbu]

Hello Check Mates, 

we have seen on three occasions that the SAML authentication method fails for Client VPN after upgrading to a new Jumbo or reinstalling the gateway from scratch (fresh install).
Reason for our fresh install was to get rid of the ext3 filesystem which we have on very old and long running firewalls.

since we rely on special custom hotfixes we are stuck to run at R81.10 HFA 110

we get this error message:

x

The error lookalike depends on how the embedded browser is built into the VPN Client, sometimes its the full browser which shows and error, sometimes the browser is embedded into the VPN client itself.

It is very hard to restore the SAML login option.
Its more like a guessing game to remove the SAML authentication from the gateway, push policy again and adding SAML again. or do many reboot or fail overs. I cannot really say what brings it back ... its more a random success to have the SAML portal working again.

anyone from the audience has seen this before?
since it struck us 3 times now, i think there is indeed a systemic reason behind it.

after some discoveries i found some interessting hints:
i see way too little Multiportals running ???

active member with broken SAML portal	working member set to standby to check behavior
[Expert@XXXY1:0:ACTIVE]# mpclient list DLPSenderPortal SecurePlatform UserCheck nac nac_transparent_auth saml-vpn	[Expert@XXXZ2:0:STANDBY]# mpclient list DLPSenderPortal ExchangeRegistration ReverseProxyClear ReverseProxySSL SecurePlatform UserCheck nac nac_transparent_auth saml-vpn sslvpn

when i check if the paths for the SAML portal do exist ... i get disappointed on the newly installed active member they missing, also some directories are not there.

path is: 
https://XXXXX.ZZZZ.com/saml-vpn/spPortal/ServiceProviderTabs?realm=vpn_XXXXX_SAML&session=6i7hz9koxb...



[Expert@XXXY1:0:ACTIVE]# find / -name ServiceProvider\*
/opt/CPSamlPortal/htdocs/spPortal/ServiceProvider
/opt/CPSamlPortal/phpincs/simplesamlphp/vendor/simplesamlphp/saml2/src/SAML2/Configuration/ServiceProvider.php
/opt/CPSamlPortal/phpincs/simplesamlphp/vendor/simplesamlphp/saml2/src/SAML2/Configuration/ServiceProviderAware.php
/opt/CPSamlPortal/spPortal_BEFORE_R81_10_jumbo_hf_main/htdocs/spPortal/ServiceProvider
/opt/CPSamlPortal/spPortal_BEFORE_R81_10_jumbo_hf_main/phpincs/simplesamlphp/vendor/simplesamlphp/saml2/src/SAML2/Configuration/ServiceProvider.php
/opt/CPSamlPortal/spPortal_BEFORE_R81_10_jumbo_hf_main/phpincs/simplesamlphp/vendor/simplesamlphp/saml2/src/SAML2/Configuration/ServiceProviderAware.php

[Expert@XXXZ2:0:STANDBY]# find / -name ServiceProvider\*
/opt/CPSamlPortal/phpincs/simplesamlphp/vendor/simplesamlphp/saml2/src/SAML2/Configuration/ServiceProvider.php
/opt/CPSamlPortal/phpincs/simplesamlphp/vendor/simplesamlphp/saml2/src/SAML2/Configuration/ServiceProviderAware.php
/opt/CPSamlPortal/htdocs/spPortal/ServiceProvider
/opt/CPSamlPortal/htdocs/spPortal/ServiceProviderTabs
/opt/CPSamlPortal/spPortal_BEFORE_R81_10_jumbo_hf_main/phpincs/simplesamlphp/vendor/simplesamlphp/saml2/src/SAML2/Configuration/ServiceProvider.php
/opt/CPSamlPortal/spPortal_BEFORE_R81_10_jumbo_hf_main/phpincs/simplesamlphp/vendor/simplesamlphp/saml2/src/SAML2/Configuration/ServiceProviderAware.php
/opt/CPSamlPortal/spPortal_BEFORE_R81_10_jumbo_hf_main/htdocs/spPortal/ServiceProvider
/opt/CPSamlPortal/spPortal_BEFORE_R81_10_jumbo_hf_main/htdocs/spPortal/ServiceProviderTabs

so it seems the directories and files to run the SAML portal where just not created ... how come?
TAC has to be involved ... 

best regards

[NiladriSarkar]

We have experienced the same issue with after we upgraded a AWS GEO cluster from r80.40 to r81. We have a case open with TAC.

The second scenario is for Maestros.. initially it was running on r81.10 take 95 + custom fix for SAML.

After upgrade to take 132 ( which required the custom fix to be uninstalled ) SAML is broken/firewall cannot be accessed using GUI,  and there are issues with IPsec tunnel rekey.  case is open with TAC for this as well. 

[Thomas_Eichelbu]

Hello yes understood.
well TAC is already working on it ... iam confident they will find it 🙂

also check this SK sk181971 but its for Error 400 and not Error 404.
i suspect i could easily transfer the folders from the working FW to the broken FW. but i want a solid hotfixes and explanation.

[alannnnnnn]

Same "Not Found" issue after upgrading to 81.10.

I noticed ServiceProvider changed to ServiceProviderTabs in the URL.

[CheckPointerXL]

I had same problem after fresh install + take 130

The fix is: uninstall JHF, install an intermediate JHF (in my case #78), then upgrade to latest JHF

[Thomas_Eichelbu]

Hello, 

TAC mentioned, this issue is known as : PRHF-33044.
if required they will build a custom fix for you.
if it affects a R81.20 fresh install is still under investigation!

best regards

[Thomas_Eichelbu · Accepted solution]

Hello, 

TAC finally solved it ...
PRHF-33044  is the Bug ID
the issue seemed to start with HFA113, which breaks some files in /opt/CPSaml file structure.

Fresh install with R81.10
install HFA in HFA 129 in my case
Install custom fix provided by TAC for HFA129
SIC + Policy Push
and SAML is working again ...

i hope they integrate it into the next GA HFA ... 
otherwise you can do it manually:

backup of both directories
and copy the good files to the affected FW.
scp -rp /opt/CPSamlPortal/* admin@XXXXX:/opt/CPSamlPortal

[I_Santos]

Yes, I did use "Fresh Install and Upgrade feature" to upgrade from R81.10 take 130 to R81.20 and I got the same issue. I had to rollback the upgrade.

[CheckPointerXL]

For anyone interested to fix the issue without the custom fix, i suggest the previous workaround:

-clean install 81.10

-install JHF 78

-Install latest JHF