Microsoft Office 365 Provisioning Error "User license is inherited from a group membership and it cannot be removed directly from the user"
Last Updated:
Overview
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
Applies To
- Microsoft Office 365
- Okta Integration Network (OIN)
- Okta Identity Engine (OIE)
- Okta Classic Engine
- Provisioning failed due to the AAD inherited group license
Cause
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.
Solution
If the target End Users have AAD licenses assigned via AAD group membership on the Azure Active Directory side, this will conflict with the Okta license assignment flow, since Okta was also configured as a new O365 license source.
To avoid any license-related provisioning errors, the customer must make a business decision on their choice of O365 license management source (Okta-managed or AAD-managed), perform the necessary configuration cleanup on the Okta or AAD end, and stick with that choice going forward.
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, the Okta Admin can retry the failed O365 provisioning job from the 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 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 the target provisioned AAD user.
- Presuming the Okta MS Office 365 provisioning app has provisioning enabled with any supported provisioning option excluding Licenses and Roles Management Only, and prefers Okta to handle only the non-license/role-related O365 app profile attribute mapping feature, Okta Admin may instead update MS Office 365 application provisioning configuration setting to "User Attributes Only" Provisioning Feature for Microsoft Office 365 in Okta. This method is optimal for customers with business requirements where Microsoft license and role management is handled outside Okta (for example, directly in Azure AD or via other tools), while still using Okta for MS user identity and attribute management only.
