External partner users lose access to partner portal after directory sync with Azure AD B2B collaboration

CRM Adobe Experience Cloud
, , , , , , , ,
1

We implemented Azure AD B2B integration to manage external partner access to our Adobe Experience Cloud partner portal. The initial setup went smoothly and guest users were provisioned correctly. However, after running the first scheduled directory sync, about 40% of our partner users lost access to the portal completely.

When they try to log in, they get authenticated through Azure AD successfully, but then receive an ‘Access Denied’ message when trying to access any partner portal resources. I’ve checked the Azure AD B2B guest user roles and they still show the correct assignments. The directory sync status shows ‘Completed Successfully’ with no errors, but clearly something went wrong with the portal access mapping. Has anyone experienced partner users losing access after Azure AD sync?

system 2

Here’s the complete solution to restore partner portal access:

1. Fix Directory Sync Configuration: In your Azure AD directory sync settings for Experience Cloud:

  • Disable ‘Normalize User Principal Names’ option
  • Enable ‘Preserve External User Identifiers’
  • In the attribute mapping section, ensure ‘userPrincipalName’ is mapped to ‘username’ with ‘Keep Original Value’ selected
  • Verify ‘userType’ attribute is mapped and set to preserve ‘Guest’ designation

2. Configure Azure AD B2B Guest User Role Mapping: Set up proper role propagation:

  • In Azure AD, verify guest users are members of designated partner groups (e.g., ‘External-Partners-Portal’)
  • In Experience Cloud Admin Console, go to Settings > Directory Sync > Group Mapping
  • Map your Azure AD partner groups to Experience Cloud permission groups for partner portal
  • Ensure the mapping includes: ‘Partner Portal User’, ‘Partner Account Manager’, and any custom partner roles
  • Save and enable ‘Automatic Group Sync’

3. Verify Portal Access Mapping: In the partner portal configuration:

  • Navigate to Partner Portal > Settings > Access Profiles
  • Confirm ‘External Guest User’ profile exists and is active
  • Verify this profile has permission sets: ‘Partner Dashboard Access’, ‘Lead Submission’, ‘Deal Registration’
  • Check that profile assignment rule: UserType = ‘Guest’ AND Domain CONTAINS partner domains

4. Check Directory Sync Status: Before proceeding with fixes:

  • In Admin Console, go to Settings > Identity > Directory Sync
  • Review sync logs for the last run that caused the issue
  • Look for warnings about user type changes or attribute mapping failures
  • Document which users were affected (export user list showing current user type)

5. Restore Affected Users: For the 40% of users who lost access:

  • Stop automatic directory sync temporarily
  • In Admin Console > Users, filter by user type ‘Member’ and domain matching partner domains
  • For each affected user, manually edit user properties:
    • Change User Type from ‘Member’ to ‘Guest’
    • Verify username contains ‘#EXT#’ format (e.g., partner_user#EXT#@yourcompany.com)
    • Assign to ‘External Guest User’ profile
    • Add to appropriate partner portal permission groups

6. Run Corrective Sync: After configuration changes:

  • In Directory Sync settings, select ‘Manual Sync’
  • Choose ‘Update Existing Users Only’ (don’t create new or delete)
  • Enable ‘Preview Mode’ first to review changes
  • Verify preview shows user type preservation and correct UPN format
  • Execute the actual sync
  • Monitor sync completion and review logs for errors

7. Validate Access Restoration: Test with affected partner users:

  • Have 2-3 partner users attempt login
  • Verify they authenticate through Azure AD B2B successfully
  • Confirm they reach partner portal home page without ‘Access Denied’
  • Test key functions: viewing partner dashboard, submitting leads, accessing resources
  • Check Admin Console to confirm user type shows ‘Guest’ and correct permission groups

8. Prevent Future Issues: Implement ongoing monitoring:

  • Set up alerts in Admin Console for user type changes
  • Schedule weekly reviews of directory sync logs
  • Create a test partner user account to validate sync before production runs
  • Document the correct sync configuration for future reference
  • Train team members on Azure AD B2B vs regular user management differences

9. Communication Plan: Notify affected partners:

  • Send email explaining the temporary access issue
  • Provide timeline for resolution (typically 2-4 hours after sync completion)
  • Include support contact for users still experiencing issues
  • Request they clear browser cache and attempt fresh login after fix is deployed

The root cause was the UPN normalization setting stripping the ‘#EXT#’ identifier from guest user accounts, which caused Experience Cloud to reclassify them as internal members and remove partner portal access. By preserving the external user identifier and restoring the correct user type, access will be restored while maintaining proper security boundaries between internal and external users.

This draft is based on general Adobe Experience Cloud knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

This sounds like a user type mismatch issue. When Azure AD B2B syncs guest users to Experience Cloud, it needs to maintain the external user designation. Check if your affected users are being converted from ‘Guest’ to ‘Member’ user type during sync. In the Admin Console, look at the user list and verify the user type column. External partners must remain as Guest users to maintain proper portal access mappings.

4

I had this exact problem last year. The issue is usually in the directory sync configuration where the user attribute mapping doesn’t preserve the external user identifier. Azure AD B2B guest users have a specific UPN format with ‘#EXT#’ in it. If your sync configuration is stripping this or normalizing the UPN, Experience Cloud loses track of which users are external and revokes their partner portal access. Check your attribute mapping rules in the sync configuration.

5

You might be onto something. I checked the Admin Console and several affected users now show as ‘Member’ type instead of ‘Guest’. Their UPNs also look different - they’re showing as normal email addresses without the ‘#EXT#’ identifier. Our sync configuration has a ‘Normalize User Principal Names’ option that was enabled by default. Could that be causing the issue?

6

Yes, that’s definitely your problem. The ‘Normalize User Principal Names’ setting is meant for internal users only. For Azure AD B2B guest users, you must preserve the original UPN format including the ‘#EXT#’ suffix because that’s how Experience Cloud identifies external users and applies the appropriate access policies. Disable that normalization setting and run a manual sync to restore the correct user attributes. You may need to manually fix the user type for affected users in the Admin Console.

8

Also verify your partner portal access mapping configuration. In the portal settings, there should be specific permission sets assigned to the ‘External Guest User’ profile. If the sync changed users from Guest to Member type, they no longer match the External Guest User profile and lose those permission sets. After fixing the user types, you’ll need to verify each affected user has the correct portal profile assigned.

9

One more thing to watch out for - Azure AD B2B guest user roles in your Azure tenant might look correct, but they don’t automatically translate to Experience Cloud permission groups. You need to map Azure AD groups to Experience Cloud permission groups in your sync configuration. Make sure your partner users are members of Azure AD groups that are mapped to the appropriate partner portal permission groups in Experience Cloud.