- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
01-02-2024 06:45 AM
Hello all .
Seem to be casting into an empty pool here but will try anyway.
My issue is with Multi Auth profiles using Global Protect & Prisma Access.
If you use more than one IDP you can only match against one profile , hence you can't use multi profile.
So recommended is CIE multi Auth .
You setup your IDPs in here , easy peasy and it works.
Only problem is when you authenticate against the CIE multi Auth .
You get a new PAlo Alto landing page which requires you to enter your user ID so CIE can work out which IDP to point you towards.
This breaks SSO completely . SO , if like me you allow Windows authentication FIRST before GP starts , CIE does not use the already granted token because it does not know which directory to point it at , hence you have to enter a users name,, it then is able to see the token is valid and authentication is satisfied and we move on .
Pretty dumb as is completely break SSO . The only option is to move from a working fully integrated IDP to one where users have to enter their user ID.
TAC tells me this is expected behaviour . I can't believe this is actually true as it makes no sense at all to break SSO .
As usual there is no documentation (or I cant find it) on how to configure Mutli Auth profiles to cater for this limitation.
There might be some Kung Fu in global protect thats allows it ?
Anyone else seen this ?????
HELP !!!
01-10-2024 01:46 AM
Hello Elizabeth32.
Finally got some traction on it . My SE Rob has been excellent.
It is expected behaviour. Ergo SSO gets broken on purpose.
The reasoning on this seem to be that CIE cannot interpret the token . So the defined method is to add a proxy type layer where the users inserts their username into a landing page and CIE directs accordingly .
The workaround is to use the default browser on the endpoint and create a dummy record in the password management of the browser for the CIE landing page, this automatically completes the users input but there is still a submit button .
It is a work around for now but it still breaks SSO .
My SE setup a meeting with the IAM guru for Europe and we went through the scenario , it is a weaknesses which is well recognised by Palo .
Seems the best way is to be able to assign an authentication profile to the Global Protect policy which takes away the need to have that proxy landing page and does away with the multi profile CIE policy .
They have actually put. a change request in for this or something similar.
Very positive input from Palo . Just a huge shame TAC were not aware of how this works and took ages to try and diagnose.
05-19-2024 07:12 PM - edited 05-19-2024 08:26 PM
This is the screen that I have seen, I have configured the group, else the multi profile wont work. I have also set default profile. The SSO is not seemless compared to pointing to Entra ID directly. Is this fixed?
@gcollins5 , may I know what's the "change request" ID, so I can reference it.
08-01-2024 12:48 AM
My bad didn't answer this . I will reach out to my SE to find it .
03-05-2025 01:22 AM
hi kengseng,
Can you now direct to entra without logging into single sign on palo?
03-18-2025 08:49 AM
Not at the moment as far as I am aware.
My experience is in using Global Protect with Entra as the IDP .
PRISMA will only support one Entra IDP . You can mess about with it a little bit and have different authentication types for different Entra directories but can only enforce for an OS . For example , macOs has one policy which uses and authentication for a different IDP etc . Bit rubbish and won't work .
The recommendation at the time was to use CIE and create a Multi Auth profile which points at two separate IDP via CIE.
Problem is , to make auth work you have to input the user and domain when GP loads . This is not SSO , in fact it breaks all the principles of SSO .
While you are waiting for input on the login , teams ,slack and any other app is failing to load on the desktop . Causes a nightmare if you use Conditional Access.
My request was to tie a Portal or Gateway policy to a CIE authentication policy , that way you don't need to input the user as it is tied to the right policy .
Looks like that fix never happened.
I would have to set it up in a lab to test to see if things have changed.
Palo use Multi Auth CIE profiles and use autofill to fill int he user request field.
05-01-2025 01:14 AM
Hello All - update 6.3.3 release of GP !
It is here :
Improvements for Multi Authentication CIE Experience When CIE (SAML) multi-authentication is configured for the GlobalProtect app as the authentication method, end users are no longer required to enter their single sign-on (SSO) credentials when they try to authenticate to the app. You can now predeploy the registry key CASSKIPHUBPAGE (path: \HKEY_LOCAL_MACHINE \SOFTWARE\Palo Alto Networks\GlobalProtect\Settings) on the Windows endpoints to enable this feature. After you enable this feature, end users are not prompted to enter their SAML credentials while authenticating to the app using the embedded browser or the default browser. This feature is supported only on Windows platforms .
It's a kiss from your auntie but a kiss all the same. Now if only macOS could deal with it !
05-19-2025 05:17 PM - edited 05-19-2025 05:22 PM
This username prompt can be skipped with Windows GP client 6.3.1+
The registry key is 'cas-skip-hub-page'=yes
or msiexec.exe /i globalprotect64.msi CASSKIPHUBPAGE=yes
https://docs.paloaltonetworks.com/whats-new/new-features/september-2024/improvements-for-multi-authe...
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!