# SAML authentication in Mobile Access Portal does not work in a Maestro Security Group in the VSX mode

**Product**: Maestro HyperScale Firewall  
**Version**: R81 (EOS), R81.10 (EOS), R81.20, R82  
**OS**: Gaia  
**Last Modified**: 2025-12-18

## Symptoms

- Mobile Access Portal does not always show the SAML icon  of the SAML Login Option.

- In a web browser, Developer Tools > "Network" tab shows that the request for the URL of the SAML Service Provider failed with error "`404 Not Found`".

Example:

## Cause

During the Access Control policy installation, the `$SAMLPORTAL_HOME/phpincs/spPortal/idpPolicy.xml` file is not updated correctly on the non-SMO Security Group Members.

## Solution

This problem was fixed. The fix is included in:

- [Jumbo Hotfix Accumulator for R82](https://sc1.checkpoint.com/documents/Jumbo_HFA/R82/Default.htm) starting from Take 44  
- [Jumbo Hotfix Accumulator for R81.20](https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.20/Default.htm) starting from Take 119  
- [Jumbo Hotfix Accumulator for R81.10](https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.10/Default.htm) starting from Take 183

If you choose not to upgrade, follow this **workaround** procedure:

The shell script `cpha_blade_config` is responsible for the policy installation task on the non-SMO Security Group Members.

**Procedure**:

01. Connect to the command line on the Security Group.

02. Log in.

03. If your default shell is Gaia gClish, then go to the Expert mode:

`expert`

04. Back up the current `cpha_blade_config` script:

`g_all cp -v $SMODIR/bin/cpha_blade_config{,_BKP}`

05. Edit the current `cpha_blade_config` script:

`vi $SMODIR/bin/cpha_blade_config`

06. Insert the call to the `$CPDIR/tmp/.CPprofile.sh` script in the required place.

The relevant section before the change:

``...

else

# in VSX we can have a lot of processes like these running simultaneously together hence we don't want to bind to only one core

LFETCH_OUTPUT=`$FWDIR/bin/fw fetchlocal -d $FWDIR/state/__tmp/FW1 $policy_type 2>&1` >> $LOGFILE 2>&1

fi

...``

The relevant section after the required change:

``...

else

# in VSX we can have a lot of processes like these running simultaneously together hence we don't want to bind to only one core

. $CPDIR/tmp/.CPprofile.sh

LFETCH_OUTPUT=`$FWDIR/bin/fw fetchlocal -d $FWDIR/state/__tmp/FW1 $policy_type 2>&1` >> $LOGFILE 2>&1

fi

...
    ``

07. Save the changes in the file and exit the Vi editor.

08. Copy the modified script to all Security Group Members:

`asg_cp2blades $SMODIR/bin/cpha_blade_config -p`

09. In SmartConsole, install the Access Control policy on the Security Gateway / relevant Virtual System object.

**Important** - In the **Install Policy** window, select " **Do not use Install Policy Acceleration for all targets**".

Example:

10. On the Security Group, make sure the file `idpPolicy.xml` is the same on all Security Group Members (SMO and non-SMO):
    1. If this Security Group works in the VSX mode, then go to the context of the relevant Virtual System:

`[Expert@HostName-ch0x-0x:0]# vsenv <VSID>`

2. Compare the file `idpPolicy.xml` on all Security Group Members:

`[Expert@HostName-ch0x-0x:<VSID>]# g_allc cat $SAMLPORTAL_HOME/phpincs/spPortal/idpPolicy.xml`

## Article Properties

**Access Level**: General  
**Status**: Approved by TAC  
**Date Created**: 2024-08-11  
**Last Modified**: 2025-12-18

#### NOTE

This solution has been verified for the specific scenario, described by the combination of Product, Version and Symptoms. It may not work in other scenarios.