topic Re: Cloud Identity Engine - Failed to get client configuration in GlobalProtect Discussions

Cloud Identity Engine - Failed to get client configuration

mb_equate — Mon, 22 Apr 2024 05:19:24 GMT

Migrating from on-prem (radius/ldap) auth & group mapping to CIE using AAD for both directory and auth types.GP porta connection fails with "Failed to get client configuration".

Things we've checked...

* CIE Auth Type configured to use the 'name' SAML claim from Azure AD, which happens to be the UPN

* CIE Group Mapping is using UPN as the primary username

* CIE auth profile on the device is restricted to AAD groups (authN works)

* The user's UPN appears in the synced group

* Serial number check in config selection criteria is none and not no

* Restart userid process

We still have the LDAP groups available, when used in the config selection criteria a user authenticated by CIE is found in the LDAP group and authZ succeeds, but strangely we see UserID transforming the UPN provided by GP from the SAML claim to the LDAP sAMAccountName i.e. domain\user which matches the LDAP group membership.

I suspect this is a hangover from the LDAP domain-map although when we dump the domain map it lists only the CIE/AAD domain and short name (client.onmicrosoft.com / client) - must I remove the LDAP group mapping? Are CIE and LDAP mutually exclusive?

Re: Cloud Identity Engine - Failed to get client configuration

Claw4609 — Tue, 23 Apr 2024 17:15:33 GMT

Hello,

I would make sure your primary username attribute and your CIE attributes match each other, that'll be easiest for moving things over.

We are currently running both LDAP and CIE SAML at the moment. we have users set to primary as UPN as it was easier to get those two to match up that way. The way your users are going to show up in your logs is going to be based off the "Primary Username" under your "Group Mapping Settings"

I would also CLI into the firewall and make sure the username is being group matched as intended: show user user-ids match-user USER

Re: Cloud Identity Engine - Failed to get client configuration

mb_equate — Fri, 26 Apr 2024 03:32:24 GMT

This works for my client (custom LDAP group and CIE SAML) as one of the user's alt user names appears in the LDAP group, but not the UPN. The UPN IS in the CIE group in the client selection criteria, but only matches when we use the LDAP group instead.

TAC have asked to check GlobalProtect is not getting the configuration when user authen... - Knowledge Base - Palo Alto Networks, which is even more confusing because a) logs identifying the normalised username don't exist in PAN-OS 11 and b) states the normalised username "is not part of the user-attributes output" despite being the primary username.

In our case, the output of "show user user-ids match-user USER" lists the user's UPN and matches the group in question.

It's possible our issue is similar to LIVEcommunity - Re: Problems with Windows User-ID Agent and the normalized Users - LIVEcommunity - 378972 (paloaltonetworks.com) where the domain-map from one LDAP group mapping is affecting another (CIE in this case).

Re: Cloud Identity Engine - Failed to get client configuration

mb_equate — Fri, 26 Apr 2024 03:48:28 GMT

I was right! Disabling the LDAP group mapping solved the issue. ALL the output of the relevant commands below are identical to the failed state, only the client config is now matching the CIE group correctly.

show user user-ids match user <upn> lists the primary username and CIE group membership used in config selection

show user user-attributes user <upn> lists the alt user name attributes from the CIE group, not that they are needed now

show user group name <group> | match <upn> lists the user as a member of the group used in config selection

debug user-id dump domain-map lists ONLY the CIE domain map (FQDN/short name).

For now I'm advising other clients migrating from LDAP to CIE to disable LDAP groups, if there are no other dependencies on those groups. Not sure what to do if there are, other than a full migration to CIE replacing groups in policy.