Azure AD + Globalprotect = unable to filter the client settings

[JoseCortijo]

Hi,

I have a Pa-850 running 10.1.8 and globalprotect 5.2.6-87.

My issue appears whenever I try to assign different "Agent->Client settings" at the gateway level based on an AD group.

The portal is configured to authenticate against Azure AD using SAML. Later the gateway is also configured to authenticate against Azure SAML.

Our local PaloAlto partner suggested configuring the gateway to authenticate against our local LDAP. When I do so, global protect client fails to authenticate the user and a prompt is shown waiting for a user and password.

Any ideas or suggestions about what I might be doing wrong?

many thanks

[aleksandar.astardzhiev]

Hi @JoseCortijo ,

First let me clarify GP portal/gateway authentication and GP portal/gateway agent config are two different thinks. Speaking in correct terminology those are authentication and authorization:

- Azure AD over SAML will provide user authentication

- GP portal/gateway Agent -> client settings based on AD group could be considered as authorization - different GP config and IP range based on group membership.

Group membership checking is done by Group Mapping. Until PanOS 10.1, FW was supporting only LDAP queries for collecting groups and group membership from local AD. You can use LDAP for GP authentication and group mapping, but it is not required. You should be able to use SAML for authentication and LDAP for group mapping.

If you already use AzureAD I would suggest you to consider Learn About the Cloud Identity Engine (paloaltonetworks.com)

Running PanOS 10.1+ you can Cloud Identity Engine (CIE) for group mapping as well. Basically your set up would be:

1. Activate and create Cloud Identity Engine app

2. Connect CIE with your AzureAD

3. Configure your FW to use the CIE. This will allow FW to collect group mapping from CIE and will not require LDAP profile

4. Configure AzureAD for SAML authentication to GP portal and gateway

5. Configure GP agent client config based on AD groups from CIE

[JoseCortijo]

Hi @aleksandar.astardzhiev ,

thanks a lot for the clarification and nice to know about CIE. Unfortunately I cannot move to CIE at the moment.

Our fw are running 10.1.8 so I should be able to authenticate with SAML and authorize with LDAP, but unfortunately, it does not work. Could you help me to troubleshoot what is failing? I went through global protect logs but found nothing that caught my attention.

In the fw side I don't know where I could find some debug information related to the issue. 

Any suggestion?

Do you think it would be a good idea go up to 10.2 version? might it help with this issue?

thanks

[aleksandar.astardzhiev]

Hi @JoseCortijo ,

It is not necessary to move to newer versions, SAML authentication + LDAP group mapping is supported and working solution for very long time and moving to 10.2 would bring benefit - in my personal opinion.

If you dig around the forum you could find that the most common problem is the username format that SAML provide when authenticating the user and creating user-ip-mapping and the username format provided by the group mapping.

I would expect that SAML is using userPrincipleName (UPN) format - you should be able to confirm this by:

- Checking your GP logs, what is the username from the logs?

- Checking your User-ID logs

- Under the definition for the Enterprise Application in AzureAD (Enterprise Applications -> <your-gp-saml-app> -> Single sign-on -> Attributes and & Claims

- Under the Authentication Profile, check what you are using for username attribute (should be username by default)

For the Group mapping you probably collect only sAMAccountName (SAM) as primary user attribute. You should be able to confirm by:

- Check your group mapping profile (Device -> User Identification -> Group Mapping -> <your-profile> -> User and Group Attributes

- Check under CLI how FW is listing group members
> show user group list | match <test-group>

> show user group name "<full-group-dn-from-above-command>"

As you can see in the Group Mapping profile you can define three alternative username attributes. This is because since several PanOS versions, FW is capable to use multiple user attributes and successfully map all to the same user. You can check all the attributes that FW is able to collect under CLI:

> show user user-attributes user <username>

In addition you may need to check if FW is able to collect All about User-ID domain map - Knowledge Base - Palo Alto Networks

It is important for the FW to be able to correctly map domain name in FQDN and NetBios format.

As summary:
- What format are you seeing the username after SAML authentication?

- Do you see the same attribute already collected by Group Mapping  (> show user user-attributes user )?
- Does FW correctly collect User-ID domain map?

[rjdahav163]

@aleksandar.astardzhiev I am having the same problem and you summarized it perfectly.

I have a group condition under GP Portal > Agent >  Config Selection Criteria > User/User Group.

My SAML is using user.userprincipalname.

My LDAP is using sAMAccountName and I have also added userPrincipalName under Alternate Username 1 under the Group Mapping settings on firewall.

Now when the user tries to login to GP, the SAML auth succeeds but still cannot connect because the portal does not identify the user as a member of the group mentioned in the group condition above GP Portal > Agent >  Config Selection Criteria > User/User Group.

How to resolve this? 

[aleksandar.astardzhiev]

Hi @rjdahav163 ,

Once you add UPN as alternative user attribute in GP you probably need to way for the next group-map to happen.

If it still not working. Can you share the following:

-

# Content of the group that is used in GP config
> show user group name "<cn-group>"

# Check if FW is able to associate different user formats
> show user user-attributes user <user.name>@<domain>

[WilliamFoisseau]

hi,

I have a same problem.

[JoseCortijo · Accepted solution]

I finally solved with the official technical support. In my case we just enabled the logging with the following CLI command

debug software logging-level set level dump service rasmgr

and we could show the not matching happening.

In our case, the culprit was a misconfiguration we had in our Group Mapping settings.

DEVICE --> User Identification --> Group Mapping Seeting-->Server Profile--> Domain Setting -->User Domain  . Here I had some short version of our domain name. I just left this setting empty so by default is extracting the domain value from the user name.

some info

https://docs.paloaltonetworks.com/pan-os/10-1/pan-os-web-interface-help/user-identification/device-u... [docs.paloaltonetworks.com]

I hope it helps.

[WilliamFoisseau]

Hi,

 It's works. 

Thank for your help

[MP18]

@JoseCortijo   So still user Portal and Gateway are configured to use Azure SAML right?

Your Gateway is not doing Authentication base don local LDAP right?

Regards

[JoseCortijo]

Exactly, the authentication is done using SAML and then the gateway client settings is filtered based on a local AD security group.And there was the issue, the Group mapping setting.

[l2-security]

Hi aleksandar.astardzhiev,

I know its a little old post, still it matters,

What if ,  we add the same usergroups locally in the firewall and try to define them in the gateway client settings.

will this work ?