Okta Microsoft Office 365 Provisioning Error User License is Inherited from a Group Membership
Last Updated:
Overview
An error occurs during the Microsoft Office 365 provisioning flow in Okta when the target Azure Active Directory (AAD) user has an inherited group license assignment. Resolve this by choosing either Okta or AAD as the single source of truth for license management and configuring the provisioning settings accordingly.
When the Microsoft Office 365 provisioning flow fails, Okta generates the following error on the 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
- Okta Identity Engine (OIE)
- Okta Classic Engine
- Microsoft Office 365
- Okta Integration Network (OIN)
- Provisioning
Cause
Microsoft generates the Microsoft Graph 400 error. This error occurs when the target provisioned AAD user has an AAD group inherited license assignment. Microsoft does not allow license changes via the Microsoft Graph API when an AAD user has an AAD group-inherited license assignment.
Solution
How is the Microsoft Office 365 inherited license provisioning error resolved?
Resolve the license-related provisioning error by selecting either Okta or AAD as the single source of truth for license management and applying the corresponding configuration.
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 regarding their 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 in which Microsoft licensing and role management are handled outside Okta (for example, directly in Azure AD or via other tools), while still using Okta only for MS user identity and attribute management.
