Forum Discussion
Restoring a user to Azure API Management instance who had registered using Azure B2C
I am trying to restore a Azure API Management user account that I had backed up and has identity.provider and intentity.id backed up. When I restore this user using the ARM endpoint using URI similar to one below, the user gets restored but has both "AadB2c" and "Basic" as the auth type:-
"https://management.azure.com/subscriptions/${subscriptionId}/resourceGroups/${resourceGroup}/providers/Microsoft.ApiManagement/service/${apimName}/users/${userId}?api-version=2024-05-01"
Why is Basic being added as the value because the backup had "AadB2c" as the Auth Type?
And is there a way to avoid that and only have "AadB2C" as the Auth type.
3 Replies
I would check the restored APIM user object first, especially the identities section.
APIM has the developer user record, and then it has the external identity link to B2C. If you recreate the user with only the normal profile fields, APIM may treat it like a local/basic developer account even though the person also exists in B2C.
The main things I would compare against a working B2C-created user are:
- the B2C identity provider is already configured on APIM before the restore
- the restored user has the same identity provider entry in identities
- the B2C object/id you are restoring still exists
- the developer portal was republished after identity provider changes
If the restored user payload matches a known good user and APIM still adds both Basic and AadB2c, I would raise a Microsoft support case with the exact PUT payload and the GET result for the user. That sounds more like APIM service behavior than a normal portal setting.
Docs that may help:
https://learn.microsoft.com/rest/api/apimanagement/user/create-or-update
https://learn.microsoft.com/azure/api-management/api-management-howto-aad-b2c
https://learn.microsoft.com/azure/api-management/api-management-howto-disaster-recovery-backup-restoreFrom what I've seen with Azure API Management user restoration, the "Basic" identity type is often added by default when a user resource is recreated through the ARM API, even if the original account was associated only with an external identity provider such as Azure ADB2C. This behavior appears to be tied to how APIM internally manages user entities rather than strictly mirroring the backed-up authentication configuration.
A few things you may want to verify:
Ensure that both identityProvider and identityId are being restored correctly in the request payload.
Check whether the user is being created via a PUT operation rather than imported through a backup/restore process, as APIM may apply default user settings during creation.
Review the latest API version documentation to see if there are any known changes in user identity handling.
As far as I know, there isn't a documented parameter that explicitly prevents APIM from associating the Basic identity type when recreating a user through the management API. If the additional auth type is causing issues, it may be worth opening a support ticket with Microsoft to confirm whether this is expected behavior or a platform limitation in the current API version.
Seems because Azure API Management automatically generates a password for restored users unless explicitly removed. This results in the user having both Basic and AadB2C authentication methods. To avoid Basic auth, you must restore the user without a password property so only the external identity (AadB2C) remains.learn.microsoft.com/en-us/answers/questions/5909027/restoring-a-user-to-azure-api-management-instance
