We recently migrated our MC Quality Excellence 2023.1 cloud instance to use Azure AD for authentication. Internal users can log in fine, but external supplier portal users are getting ‘Access Denied’ errors when trying to access their supplier dashboards.
The suppliers receive the invitation email, click the link, authenticate successfully through Azure AD B2B, but then hit this error:
Error 403: Access Denied
User authenticated but not authorized for Supplier Portal
Contact your administrator
Before the Azure AD migration, these same suppliers had no issues with username/password authentication. It seems like the Azure AD groups aren’t mapping correctly to MC supplier portal permissions. Our onboarding process is completely blocked - we have 15 new suppliers waiting for access.
Has anyone successfully configured Azure AD group mapping for external supplier users in MC cloud?
Look at the Azure AD group membership propagation timing. When you add a guest user to a group, it can take 15-30 minutes for the group membership to sync and be included in the authentication token. If suppliers try to log in immediately after being added to groups, they’ll authenticate but won’t have the right claims yet. We implemented a 1-hour wait period in our supplier onboarding process to account for this delay.
This is a common issue with Azure AD B2B guest users. The problem is that external users don’t automatically inherit group memberships the same way internal users do. You need to explicitly assign them to the correct Azure AD groups that map to MC supplier portal roles.
We encountered this exact scenario. The issue was that our Azure AD conditional access policies were blocking guest users from certain applications by default. We had to create a specific policy that allows B2B guests to access the MC application. Additionally, the supplier portal role assignment happens through group claims in the SAML token, so make sure those claims are configured in your Azure AD enterprise application settings for MC.
The user sync is probably the culprit. After Azure AD authentication succeeds, MC needs to look up the user in its database and match them to a supplier organization. If the user email in Azure AD doesn’t exactly match the email in the MC supplier contact record, the lookup fails and you get access denied. Check for email case sensitivity mismatches or different email domains between the two systems.
Check your MC Admin Console under User Management > External Access. There’s a setting for ‘Auto-provision External Users’ that needs to be enabled after Azure AD integration. Without this, authenticated users won’t automatically get their MC user profile created, causing the authorization failure even though authentication succeeds. Also verify the Azure AD app registration has the correct API permissions for user profile read.