DanE.22295 (Customer) asked a question.
We have run into an interesting issue and currently working through it with Okta and Microsoft. I will update if we get a resolution.
The issue was recognized when attempting to provision users' MS365 licensing. The task would fail with: Received response with HTTP status code 403. httpStatusCode=403 errorCode=Authorization_RequestDenied errorMessage="Insufficient privileges to complete the operation."
The specific code line was: method=POST url=https://graph.microsoft.com/v1.0/users/[userid]/microsoft.graph.assignLicense
In digging into the problem the pattern was with users that had a specific Team licenses: "Microsoft_Teams_Exploratory_Dept" (SKUID: e0dfc8b9-9531-4ec8-94b4-9fec23b05fc8)
This was not a license we as MS365 Admins had given. It was showing up on accounts on it's own and labeled as a 'Self-Service' license. I am not allowed to remove it from the web gui and get a similar error of "Insufficient privileges to complete this operation" when attempting from Powershell cli. (Account used has Global Admin)
Current theory:
-User has signed up for Team Exploratory license under 'self-service'. As a non-enterprise issued license, the global admin account does not have permissions to remove or edit the license. As evident by testing and online documentation.
-When Okta attempts to connect to MSGraph and reconcile the assigned licenses in Okta with MS365 the sync fails because of the lack of permissions. This causes all license skus to not sync leaving the licenses out of sync between Okta and MS365.
Workaround:
For the 20 users with this self-service license we are having to address any MS365 license changes in the MS365 web gui and not in Okta.
-I have disabled the ability to sign up for further trial licenses at the tenant level and for Teams Exploratory as a product.
*However, license SKUids do not match documentation. One is called 'Teams Exploratory' vs 'Microsoft Teams Exploratory Dept' so concern is this is not fully addressed yet.
Proposed Solution:
-I believe the MSGraph API or the self-service product offering needs to change at Microsoft, however, a possible solution for Okta:
--Do not try to reconcile self-service licenses between Okta and MS365. (knowing these can't be altered by the tenant admin/service account)
References:
https://learn.microsoft.com/en-us/microsoftteams/teams-exploratory
Hello @DanE.22295 (Customer) Thank you for reacting out to our Community!
Another workaround that you could try is to import one of the affected users, then match the licences that are imported from Office with a group assignment and assign all affected users to that specific group, this should resolved the current issue.
Community members help others by clicking Like or Select as Best on responses. Try it today.
💡 Community Moderator Tip: Join a group today and connect with other Okta customers by region or product.
Thanks for the idea Paul. I have the users assigned the 365 app currently and they have a failed task pending, but otherwise their Okta account status is in good standing. I ran an import in the 365app, but none of those users came up as needing to be confirmed. I had hoped that would update their app profile data. For grins I ran an API call against Okta of their application profile ({{baseUrl}}/api/v1/apps/:appId/users/:userId). It only returned the details on their non-teams based licenses. It does reflect the Status of their profile as Staged, and syncStatus: ERROR and not having a recent lastUpdated field.
Maybe I'm going about it wrong, was there a different way to import this user? For reference Azure is not our directory source but a CSV file from our HR platform. So Azure is typically outbound pushes and not inbound imports.
Thanks