GlobalProtect Gateway with Multiple Client Authentication Config

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

GlobalProtect Gateway with Multiple Client Authentication Config

L1 Bithead

Hi there,

 

I have multiple client authentication configurations set up on my GlobalProtect portal which use the same OS type.

Order is as follows:

 

1 - Windows OS with local auth on the firewall.

2 - Windows OS with LDAP auth.

 

What i want to achieve is if authentication fails with local auth, it tries LDAP auth and keeps going down the list until it matches.

Both my local auth and LDAP auth profiles work fine, but the first one always takes precedence. It appears that if a config matches and fails, it does not try the next in the list.

 

I want users who perform local auth to have a different IP range assigned to users that perform LDAP auth.

How could i address this problem, or achieve the desired outcome another way?

 

Many thanks,

7 REPLIES 7

L7 Applicator

not sure of your exact config but perhaps try this,,,

 

only have 1 portal config to 1 gateway  (or multiple gateways)

 

Then on the gateway under client settings add user groups under different configs to assign different pools.

I have a similar situation.  I am trying to use two client authentication methods, one SAML (okta) and one regular LDAP.  They both point to different Active Directory groups and the regular ldap is first in order.  I have tested and when GP doesn't see the user in the regular LDAP client I receive error that user is not in allowed list and it stops and does not try the second in the list for locating the user.

L2 Linker

There is no real benefit for you using multiple client authentication configurations on your GlobalProtect portal.

Create a new authentication sequence with both authentication profiles in the correct order. Then assign this auth sequence to your one and only client authentication configuration.

 

Under Agent tab you can differentiate between those users and forward each of the user groups to a different gateway with different IP ranges.

unfortunately this doesn't resolve the issue if you are using SAML authentication (apparently authentication sequence does not support SAML authentication profiles). Any other way of doing this? So far we have created a portal for each gateway to go around this, but now we are hitting an unadvertised limit of 32 portals (5220). So basically we are stuck at 32 max VPN portal/gateways. Any thoughts/ideas are appreciated.

 

Best,

Eilbron

Hi @Eilbron 

What are you trying to do exactly? Different IP-Ranges for different user/device combinations?

Hi Vsys_remo,

We use this for external customers (Customer1/Gateway1/Portal1, Customer2/Gateway2/Portal2, and so on) where they land in their own environment (think cloud environment for customers). So far the 1:1 Portal/Gateway worked fine. But now we hit this 32 portal limit, and we are stuck. I was thinking to use one portal for multiple gateways, but under Portals > Authentication > Client Authentication, when I list multiple client authentication (for multiple customers), it only considers the first one, and does not go to the next one. The Authentication sequence option could have potentially fixed this (got excited when I saw this here), but it apparently does not work for SAML authentication. Any advice is greatly appreciated!

Best,

Eilbron

Hi @Eilbron 

Ok, got it and unfortunately you are right about this limitation. The only thing I can think of is that you install another SAML IdP in the role of some sort of "router". So the users enter their email/upn on that IdP and are then forwarded based on the domainsuffix to their actual SAML IdP. This way you could use one portal and based on the user that logs in the portal is able to assign the right config. But unfortunately it could be possible that you then hit another limitation but I am not sure about that - maybe the limitation of 32 also applies to globalprotect gateways.

Anyway this probably you can also solve with different VRs/policy based forwarding rules.

  • 7835 Views
  • 7 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!