During deployment of Private Access with ZTNA (Zero Trust Network Access), enrollment of a guest user with a personal Google account fails after successful registration in Entra ID and provisioning in Secure Access. The specific symptoms encountered include:
These failures prevent access to private resources and impact testing of ZTNA functionality for contractor-style access using non-corporate identities.
The enrollment failure was resolved by modifying the SAML attribute mapping configuration in Microsoft Entra ID. The following steps were taken to address the issue:
Review the DART bundle to confirm that Cisco Secure Client and ZTA components are operating normally. The analysis should verify that the enrollment flow successfully reaches Cisco Secure Access and that the failure occurs during SAML authentication with the Identity Provider.
Check the Entra ID authentication logs to confirm that the authentication process completes successfully from the Identity Provider perspective. The logs should show successful authentication, but Secure Access rejects the login due to attribute mismatch.
Determine that Entra ID is issuing the UPN (User Principal Name) as the SAML claim, which does not match the personal Gmail account identity expected by Secure Access. The asserted IdP attribute does not correspond to the expected user identifier.
Change the SAML attribute mapping in Microsoft Entra ID from UPN to Email Address. This ensures that the email address claim matches the personal Google account identity.
After implementing the attribute mapping change, retry the ZTNA enrollment process. Cisco Secure Access ZTA should now recognize the Gmail address and allow the enrollment to complete successfully.
The enrollment failure was caused by a mismatch between the SAML attribute being asserted by Microsoft Entra ID and the expected user identifier in Cisco Secure Access. Entra ID was configured to send the UPN (User Principal Name) as the SAML claim, but for personal Google accounts (@gmail.com), this UPN did not correspond to the actual email address identity. Cisco Secure Access expected to receive the email address as the identifying attribute to match against the provisioned guest user account, resulting in authentication rejection despite successful IdP authentication.
| Revision | Publish Date | Comments |
|---|---|---|
1.0 |
19-May-2026
|
Initial Release |