Cloud Identity Engine - Failed to get client configuration

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Cloud Identity Engine - Failed to get client configuration

L3 Networker

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?

1 accepted solution

Accepted Solutions

L3 Networker

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.

View solution in original post

3 REPLIES 3

L4 Transporter

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

L3 Networker

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 Netw..., 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 - 3... where the domain-map from one LDAP group mapping is affecting another (CIE in this case).

L3 Networker

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.

  • 1 accepted solution
  • 336 Views
  • 3 replies
  • 0 Likes
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!