I bumped into a rather annoying issue with Global Protect.
We needed and external authentication source for MFA with our Global Protect deployment, so we set up OKTA SSO (with SAML) for our Global Protect Portal. In order to Group mapping to work with the external Okta directory, we needed to set up an LDAP profile, configure user mapping and configure the Okta Global Protect app to send username in the DOMAIN\username format. (we need group mapping to work for config selection and Clientless VPN apps). It works as expected, on Portal login, the users are redirected to Okta for sign in, and on successful auth, the user is logged in to the Portal.
And here's my issue. For External Gateway we need another authentication source (in this case an internal LDAP profile) AND client cert authentication. The authentication fails on the external gateway with the error "Username in client cert is different from the input".
That is because, the client cert CN = username, but the portal forwards the username to the external gateway in myorg-okta.com/username format.
As a workaround I tried to set the Certificate profiles' (linked to the External Gateway Auth Tab) Username field from "Subject" to none. Result was the External GW auth window popped up, the username field was auto filled with myorg.okta.com\username prompting for password.
Now if I delete the DOMAIN part of username input, the client can successfuly authenticate against the internal LDAP profile. Problem is, the users would need to manually delete the DOMAIN part of the username each time they log on.
I tried the authentication modifiers in the internal auth profile but it didn't work out. Because the internal LDAP profile points to Active Directory, the %USERDOMAIN%\%USERINPUT% format doesn't work, as AD does not support DOMAIN\username format with the sAMAccountName attribute. When I try 'None' with authentication modifiers it strips the DOMAIN name part of the username as expected, but because of that I run into "Matching client config not found" issue, and that's because the Agent configuration is linked to user groups existing in the internal AD.
Maybe I'm missing something obvious, but my question is, is there a way to prevent the Global Protect Portal to forward the username (used to log in to the Portal) to the external gateway automatically? Or in another way, can I "present" a completley blank authentication form for users trying to log in to the External Gateway?
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!