Global Protect Authentication with Okta Radius + LDAP Group Mapping

[Carson1998]

Recently stood up a GP Portal and Gateway for the company that I work for. At the moment, I just have a radius-auth-profile setup to point to our internal OKTA MFA Agent which works fine, however, I also need to read and identify Security Groups using AD so I can place users in specific GP permissions (split tunnel, no-split tunnel, ACLs, Department ACLs....). My question is, Is it possible to continue to use my OKTA radius profile but also combine LDAP User Group Mappings to provide these security group-specific settings? Or has anyone tried doing this before in production? Thanks.

[TomYoung]

Hi @Carson1998 ,

Is it possible to continue to use my OKTA radius profile but also combine LDAP User Group Mappings to provide these security group-specific settings?  Yes.

Or has anyone tried doing this before in production?  I may have done this for a customer years ago.  The implementation is the same for User-ID, which I use in production.

Is does not matter if the authentication profile uses RADIUS and the group mapping uses LDAP.  What matters is that the username matches.  The GP username will most likely be in the format "username" while the LDAP username will most likely be in the format "domain/username".  These will not match.   The simplest way to make them match is to configure your authentication profile for User Domain = domain and Username Modifier = None.

This doc has a very cool table on the bottom that shows the behavior for the different configurations -> https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000boHMCAY.  In your case, the username format to match the LDAP groups for the agent config will correspond to the Allow List column.

To see the username format retrieved by the LDAP groups, use the CLI commands in this doc -> https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClVcCAK.

To see the username format for the GP user you can look at the GP logs, User-ID logs, or use the CLI command "show user ip-user-mapping all".  The format for the GP user and group list should match exactly.

Thanks,

Tom

PS Definitely use the Group Include List under your group mapping so that the NGFW only queries for users in those groups.  That saves lots of CPU cycles.

[aleksandar.astardzhiev]

---

@TomYoung wrote:

....

PS Definitely use the Group Include List under your group mapping so that the NGFW only queries for users in those groups.  That saves lots of CPU cycles.

---

Or use Cloud Identity Engine, which automatically sends only the groups that are used by FW (in policy, GP or allow list) without the need to manually define include list 🙂