When authentication moves from LDAP-based Windows Active Directory to SAML with Microsoft Entra ID, the identity string the firewall receives for a given user typically changes format — Active Directory–style LDAP authentication commonly surfaces usernames in a sAMAccountName or domain\username form, while SAML assertions from Entra ID typically populate the NameID or subject using userPrincipalName (an email-style identifier). If group mapping was originally built and is still configured to match on the older AD-style attribute, it will no longer correctly correlate the identity string now being delivered via SAML with the correct directory group membership, causing existing group-based Security policy rules to stop matching even though authentication itself succeeds. The fix is to update the group mapping ' s User Attributes configuration so that it recognizes and correlates on userPrincipalName, aligning the attribute used for matching with the format Entra ID actually returns — this is precisely what option C describes and directly resolves the mismatch. Configuring a redistribution profile from the old GlobalProtect firewalls (option A) addresses migrating stale mapping data from the legacy platform, not the fundamental attribute-format mismatch introduced by switching to Entra ID SAML. Migrating group mapping to the Cloud Identity Engine via an AD query agent (option B) does not resolve the issue either, since the root problem is the mismatched attribute used for correlation, not the source of the group data itself. Changing the SAML Username Modifier (option D) affects how the username is formatted for display or session purposes, not how group mapping attribute correlation is performed for policy matching.