Consuming user group in GlobalProtect SAML Authentication

Reply
JohnWade
L2 Linker

For what its worth, support confirmed that there is no group support with SAML authentication.  They referenced a prisma document: https://docs.paloaltonetworks.com/prisma/prisma-access/prisma-access-panorama-integration/authentica...  which does state: 

 

"You can’t use group information that’s retrieved from the SAML assertion in either security policies or the agent client configuration in the portal and gateways. If you have a requirement to configure user group-based policies and configuration selections, you must Enable Group Mapping and retrieve the user group information from the LDAP server using Group Mapping Settings."

 

However I did find an unsupported workaround at least in 8.1.   If you can do LDAP group mapping but want to use SAML authentication (which is what we want to support multifactor), then if you send over the SAML username in the form <domain>\<username> , it will match up to the AD/LDAP user and use the group mappings from LDAP, this may be what Ozamir references above.

 

This is no help for people who want to use Google exclusively. 

 

It is definitely an incomplete implementation since the SAML configuration supports both an "Access Domain Attribute" and a "User Group Attribute" but it does not use either one for global protect. (These are only used for Mgmt SAML authentication).

 

Hope this information helps someone else.

SShnap
L3 Networker

Hi There

 

I had the same issue with SAML and LDAP group memberships, I'm using DUO with global protect and my intend was to customize the application based on group memberships.

I used @JohnWade solution and under authentication profile I changed username attributes from user.username (as DUO instruction) to <domain>\<username> and it is working great.

thank you for the help.

ddixit
L0 Member

All you need is the Metadata after configuring the app for your portal/gateway in the Google IDP.  You need two different apps for Portal and gateway if the addresses are different, unlike in Okta google doesn't support multiple URLs in a single app. 

 

goto SAML identity> create a server profile by importing the metadata.

create an Authentication profile and call the SAML server profile you created.

goto your portal and gateway > authentication> Set it to the authentication profile you created. Commit the changes.

Victor1
L0 Member

We did this with Azure AD as well.

Out basic setup is as follows:

  1. Configure the LDAP Server profile for the on-premise AD infrastructure (Base DN is in the following format "DC=domain,DC=local" )
  2. Configure SAML IdP to work with Azure AD
  3. Configure Group-Mapping using the LDAP profile. On the "User and Group Attributes" tab, we swapped "Primary Username" to be "userPrincipleName" and "Alternate Username 1" to be "sAMAccountName"
    This way the SAML username attribute matches the LDAP username attribute
  4. On the GlobalProtect side, we specified the group in the configs in the following format: "CN=User Group Name,OU=org unit,DC=domain,DC=local"
    When we tried it in the "domain\group name" format, we had no success, but we found a post on reddit that suggested trying either format to see what works in your environment. Apparently the format is dependent on how your AD infrastructure is setup.
Tags (3)
GREMAUDO
L1 Bithead

Hello,

 

This is indeed an excellent workaround, tested here also in 8.1. Thanks for this information, it's really useful.

 

Usually, we rely on our Active Directory, which is old enough to be primarily based on the SAM Account Name, which is what the NGFW is looking for by default, in the following format : Domain\SAMAccountName (ie. acme\doej)

We began using Okta to authenticate our GlobalProtect users for non-Windows or non-Domain devices, but it was impossible to use the "groups" attribute from the SAML assertion in the GlobalProtect configuration.

 

We opened a case with TAC, and the answer was the following : this attribute can only be used in the "Allow List" of the Authentication Profile, but nowhere else :

GREMAUDO_0-1604665329252.png

 

In order to make this work, the username sent by Okta in the assertion must be the same as the username that the NGFW understand by default, that is, the "Domain\SAMAccountName". This is not an easily available option in Okta.

In the GlobalProtect app in Okta :

2020-11-06_13h36_26.png

  • Edit the "Sign On" settings
  • Find "Credentials Details" section
  • Select "Custom" in the "Application username format"
  • Fill the field with this syntax : "yourdomain\" + toLowerCase(active_directory_xxxx.samAccountName)
    Please note that the "active_directory_xxxx" must match your directory ID, that you can find in the

2020-11-06_13h39_51.png

 

This only works, however, if you have an LDAP server somewhere... With Okta, I know there is a way to use it as an LDAP server, which might do the trick, like described in this link : https://help.okta.com/en/prod/Content/Topics/Directory/LDAP-interface-main.htm

 

With all this combined with a bit of Group-Mapping, you could tinker this to work as expected !

 

It's unfortunate that PAN does not seem to want to integrate a wider use of the group attribute of the SAML Assertion. It complexifies the use of SAML, with little to no documentation...

 

 

CCIE11129
L0 Member

I have been attempting this with Azure SAML. Currently I don't see the group attribute being sent by Azure so I can't test what I was wanting to test.

 

I found a document that showed an example of Admin Role being used from SAML attribute where the role name matched a GlobalProtect admin role. I wondered if this same concept would work for an empty local user group on GlobalProtect. Even though I can't use the group attribute from SAML assertion, I can use an empty local user group and was hopeful that the group sent from SAML with the same name as a local user group would work the same way admin role assertion does.

 

Have you created an empty local group in GlobalProtect and put it in a VPN matching policy and see if the SAML group assertion with the same group name would trigger a policy match?

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!