Microsoft Office 365 provisioning flow fails with the following error visible in the Okta dashboard:
Could not push profile for Office 365 user <username>, received error: Received response with HTTP status code 400. httpStatusCode=400 errorCode=Request_BadRequest errorMessage="User license is inherited from a group membership and it cannot be removed directly from the user." client-request-id= request-id= timestamp='Fri, 06 Jan 2023 04:18:19 GMT' method=POST
On the Microsoft side, the following error is visible in the logs:
Microsoft.Online.Administration.InvalidOperationOnGroupInheritedLicenseException
- Microsoft Office 365
- Okta Integration Network (OIN)
- Provisioning failed due to the AAD inherited group license
The MS Graph 400 error was thrown by Microsoft and not Okta. This error normally occurs when the target provisioned AAD user has been assigned with an AAD group inherited license assignment. This results in a failure of the MS Graph assign license API POST call as per MS product design since MS does not allow any license changes via MS Graph API call if the AAD user has an AAD group inherited license assignment.
If the target End Users have AAD licenses assigned via AAD group membership on the Azure Active Directory side, this will create a conflict with the Okta license assignment flow, as Okta was also configured as a new O365 license source.
To avoid any license-related provisioning error, the customer must make a business decision and determine what would be their choice of O365 license management source (Okta-managed or AAD-managed) and perform the necessary configuration cleanup on the Okta end or AAD end, then stick to that onwards.
Depending on the customer team's business decision:
- If the customer is committed to switching to Okta as the only source of truth for O365 license management, please work with the AAD Administrator to disable any pre-existing Azure Active Directory group membership licenses from the AAD users' object. Then, Okta Admin can retry the failed O365 provisioning job from Okta Admin Console > Dashboard > Tasks page.
- If the customer decides to keep MS AAD as the only source of truth for O365 license management, proceed to FULLY DISABLE App Provisioning integration from the existing OIN Office 365 app, as all the four supported provisioning types will allow Okta to act as the source of truth for O365 license/role management and attempt to push license/role update to target provisioned AAD user.
- If the admin wants Okta to handle only the non-license/role-related O365 app profile attribute mapping feature, then the only option is to create a custom Okta Workflow to handle those via individual O365 connector API calls. This requires a valid Okta Workflow subscription plan, so please check with the designated Okta Account Executive to see if the current Okta subscription includes the Okta Workflow product add-on.
