Best method to permit SAML auth and Radius for Globalprotect at the same time?

[mannix]

Greetings all, I hope you can help me. 

I currently have Globalprotect set up on a single firewall - both portal and gateway.  We're using Radius for authentication, it is working well. 

We want to transition to SAML.  For testing purposes, we'd like to have SAML configured for a specific test user (or group), while leaving the current authentication scheme in place. 

Reordering "Client authentication" does not do it - if I put "SAML-GP" in the first position, SAML works, but no one else can authenticate.  I'm not sure I understand why client authentication order can be changed, but that's the behavior I'm getting. 

I'd RATHER not re-ip everything.  I'm thinking that a separate portal with different public IP is the answer; do I have to add a second gateway, too?  

I don't THINK I do, if I simply specify the current gateway in the portal config. 

Thoughts?  Am I overcomplicating things?

Thanks!

Iain

[Raido_Rattameister]

If you move SAML to the top then SAML takes precedence because your OS type is "any".

You can't use both SAML and RADIUS on same portal/gateway at the same time for different groups of users.

[mannix]

Thanks very much!  

Can I use a different portal for initial auth, then continue with my current gateway?  

Iain

[Raido_Rattameister]

Yes you can.

Keep portal as is and set up new gateway.

Using user or group membership point some users to new gateway.

[Brandon_Wertz]

---

@mannix wrote:

Greetings all, I hope you can help me. 

I currently have Globalprotect set up on a single firewall - both portal and gateway.  We're using Radius for authentication, it is working well. 

We want to transition to SAML.  For testing purposes, we'd like to have SAML configured for a specific test user (or group), while leaving the current authentication scheme in place. 

Reordering "Client authentication" does not do it - if I put "SAML-GP" in the first position, SAML works, but no one else can authenticate.  I'm not sure I understand why client authentication order can be changed, but that's the behavior I'm getting. 

I'd RATHER not re-ip everything.  I'm thinking that a separate portal with different public IP is the answer; do I have to add a second gateway, too?  

I don't THINK I do, if I simply specify the current gateway in the portal config. 

Thoughts?  Am I overcomplicating things?

Thanks!

Iain

---

We've recently switched to SAML auth for our GP, and we're told that if using SAML for auth that is the only auth mechanism that can be used.  So no matter how many mechanism you use in an auth profile if SAML is there only SAML will be used.

Not too sure how accurate that is, but that's what we were told from our SE.

[mannix]

What about the inverse - adding a portal, and within that portal, configure my existing external gateway?

I'm trying to create a situation where I can have test users authenticate with saml/Azure, without impacting our existing users. 

My thought was to create a second portal, with a different public IP/natted to a loopback.  Check "Generate cookie for authentication override" in the authentication portion of the portal config. 

That way, I can configure portal2 to use SAML, other users will be none the wiser. 

What am I missing?  I _THINK_ this will work.  

Thanks!

Iain

[rfairfield]

We trying to do the same thing in our environment. Support had told us that we could add SAML auth to our existing portal/gateway configuration and that users would connect via SAML if their user was in the auth source user list, if not they'd continue to connect via RADIUS. That turned out to be false!

A second support tech informed us that you cannot do auth sequencing with SAML.

So I now have an active case open with Palo support asking essentially the same question you're asking here. However, they are just linking me to KB articles about multiple gateway configurations, not multiple portal configurations. I cannot get a clear answer. Very frustrating.

[Adrian_Jensen]

Yes, this seems to be very confusing in the documentation. As far as I have been able to determine and tested, there are 3 different methods of authentication which can not be interchanged in an authorization sequence: Certificates, SAML, and User/Password (via AD/LDAP/Radius/etc.).

This is because the 3 methods occur at different points in the client connection. The certificate authentication happens during the initial SSL/TLS and webserver connection. The SAML authentication happens after connection is established and the server requests an authorization token before fulfilling the web request. The User/Password is after the client has connected, requested a page, is sent a login prompt, and has replied with a credential set.

As you can't send a SAML token before you have established a certificate-verified web connection, and you can't submit user/pass responses before you have SAML-token-verified web request, you can't intermix these authentication methods. The AD/LDAP/Radius authentication sequences works as the client connects, is sent an authentication page, and returns a user/pass credential response. The PA can then test that single response against multiple authentication servers in the authorization sequence. Certificates and SAML don't use user/pass credentials.