This article will explain what may cause this O365 provisioning error during new app assignments or subsequent push profile update provisioning tasks for existing app assignments and the steps to remedy the issue.
Automatic profile push of user <user> to app Microsoft Office 365 failed: Could not push profile for Office 365 user <user>, received error: Received response with HTTP status code 403. httpStatusCode=403 errorCode=Authorization_RequestDenied errorMessage="Insufficient privileges to complete the operation." client-request-id=YYYYYY request-id=ZZZZZZZ timestamp='Wed, 23 Aug 2023 16:13:42 GMT' method=POST url=https://graph.microsoft.com/v1.0/users/<UserId>/microsoft.graph.assignLicense
- Office 365
- Okta Integration Network (OIN)
As the provisioning error message stated, the "403 insufficient privilege" error itself is being thrown by Microsoft directly while Okta sending MS Graph API POST https://graph.microsoft.com/v1.0/users/[azure user id}/microsoft.graph.assignLicense for:
- Initial app user provisioning during application assignment.
- During subsequent push profile update events for pre-existing application assignments.
From experience, this issue normally only occurs to specific O365 application assignments when the target provisioned Azure Active Directory (AAD) user object has been assigned with one or more self-service purchased MS license or any MS license that was purchased via 3rd party MS vendor directly in Microsoft tenant via Azure AD Directory.
Example of self-service license in Microsoft 365 Admin Center:
For example, in the Office 365 application assignment, Licenses A, B, and C were selected. In AAD, the target provisioned AAD user object has Licenses A, B, C, and D. During the Okta O365 profile push provisioning task, Okta will send a request to replace the old license assignment value (A, B, C, D) with new license assignment value (A, B, C).
If License D, which it attempts to unassign from the AAD user, happens to belong to a Microsoft license subscription plan to which the O365 service integration global admin user account has no access, either via (a) self-service purchased MS license or (b) a third-party managed license subscription plan, then the chances are the O365 provisioning task will fail with 403 insufficient privilege error.
As a result, when the application assignment, which contains a new set of O365 license assignments, attempts to replace/remove those self-service purchased or 3rd partner-managed Microsoft licenses with the new set of licenses assigned by Okta O365 app assignment O365 License Assignment selection, the MS Graph API POST https://graph.microsoft.com/v1.0/users/<UserId>/microsoft.graph.assignLicense call will fail due to 403 insufficient privilege error as Okta O365 service integration global admin user does not have the correct permission to access nor manage those self-service purchased MS license or 3rd-party managed MS license.
This is not an issue that can be solved from Okta as there is nothing wrong with the assignment configuration. The problematic MS license must be removed from the AAD user assigned the license.
We recommend that the Okta Admin work with their Azure AD Admin and contact Microsoft Support as necessary for further issue investigation on the Microsoft product side:
- Create a brand new test user in Okta who does not yet exist in the Office 365/Azure AD user directory.
- Assign the O365 app to the newly created user with an identical O365 license assignment as the problematic app assigned user, which experiences the mentioned 403 insufficient privilege error.
- Okta Admin will verify this new app assignment is completed successfully without any provisioning error. Azure AD Admin user then verifies the new user is being created in the Azure AD directory with the set of MS licenses selected during Okta Office 365 app assignment.
Using this working user example, have the AAD user compared with one or more problematic users in Azure AD on each user assigned Microsoft license list for any license assignment differences, as any additional license that was not found during Office 365 app assignment will be overridden and remove by the new license assignment.
If the Azure Administrator is unable to identify which exact assigned license is causing the issue here or has no option to remove those licenses from the AAD Admin Console, we strongly recommend contacting Microsoft Support to help identify and remove/convert any of the problematic MS licenses from the MS tenant/AAD user account.
Once the AAD Admin user/Microsoft Support Engineer has confirmed all the problematic MS license assignment has been removed from the existing AAD user object, Okta Admin can then retry the previously failed provisioning task/app assignment task from:
- Okta Admin Console > Dashboard > Tasks page, and the previous provisioning error should no longer appear.
