j5v7c (j5v7c) asked a question.
How do I use automatic provisioning of office 365 user failing
How do I use automatic provisioning of office 365 user failing
- j5v7c (j5v7c)"Automatic provisioning of user [Current O365 Azure UPN] to app Microsoft Office 365 failed: Could not push profile for Office 365 user [Current O365 Azure UPN] received error: 400 You must provide a required property: Parameter name: FederatedUser.SourceAnchor." Okta Office 365 User Management will fail if the ImmutableId value in Okta doesn't match what has been set in Office 365. There are a couple of ways this can happen. In order to fix it, you need to set the ImmutableId in office 365 to the correct value. If the User is an AD user, the ImmutableID is set to AD GUID. If the user is an Okta Only User, the immutable ID is set to the application assignment ID. You can see the ImmutableId in office 365 by running the following Azure PowerShell Commands: get-msoluser -UserPrincipalName [Current O365 Azure UPN]| select * If this does not match the AD GUID or the app assignment ID it can be reset only by changing the UPN to a non-federated domain. Once you switch the UPN for the user to a non-federated domain, reset the the ImmutableId and then change the UPN back using the following commands: Set-MsolUserPrincipalName -UserPrincipalName [Current O365 Azure UPN] -NewUserPrincipalName [temp@yourdomain.onmicrosoft.com(mailto:temp@yourdomain.onmicrosoft.com)] Set-MsolUser -UserPrincipalName [temp@yourdomain.onmicrosoft.com(mailto:temp@yourdomain.onmicrosoft.com) -ImmutableId [Either the GUID in AD or the App Assignment ID] Next, re-run the get command for the temp user to make sure the ImmutableId was reset. get-msoluser -UserPrincipalName [temp@yourdomain.onmicrosoft.com(mailto:temp@yourdomain.onmicrosoft.com)]| select * If the domain is correct, set the username back and give office 365 a couple of minutes then try re-running the user management in Okta. Set-MsolUserPrincipalName -UserPrincipalName [temp@yourdomain.onmicrosoft.com(mailto:temp@yourdomain.onmicrosoft.com)] -NewUserPrincipalName [Previous O365 Azure UPN] Original Author: Joel Hanson, Sales Engineer, OktaExpand Post
- j5v7c (j5v7c)"Automatic provisioning of user [Current O365 Azure UPN] to app Microsoft Office 365 failed: Could not push profile for Office 365 user [Current O365 Azure UPN] received error: 400 You must provide a required property: Parameter name: FederatedUser.SourceAnchor." Okta Office 365 User Management will fail if the ImmutableId value in Okta doesn't match what has been set in Office 365. There are a couple of ways this can happen. In order to fix it, you need to set the ImmutableId in office 365 to the correct value. If the User is an AD user, the ImmutableID is set to AD GUID. If the user is an Okta Only User, the immutable ID is set to the application assignment ID. You can see the ImmutableId in office 365 by running the following Azure PowerShell Commands: get-msoluser -UserPrincipalName [Current O365 Azure UPN]| select * If this does not match the AD GUID or the app assignment ID it can be reset only by changing the UPN to a non-federated domain. Once you switch the UPN for the user to a non-federated domain, reset the the ImmutableId and then change the UPN back using the following commands: Set-MsolUserPrincipalName -UserPrincipalName [Current O365 Azure UPN] -NewUserPrincipalName [temp@yourdomain.onmicrosoft.com(mailto:temp@yourdomain.onmicrosoft.com)] Set-MsolUser -UserPrincipalName [temp@yourdomain.onmicrosoft.com(mailto:temp@yourdomain.onmicrosoft.com) -ImmutableId [Either the GUID in AD or the App Assignment ID] Next, re-run the get command for the temp user to make sure the ImmutableId was reset. get-msoluser -UserPrincipalName [temp@yourdomain.onmicrosoft.com(mailto:temp@yourdomain.onmicrosoft.com)]| select * If the domain is correct, set the username back and give office 365 a couple of minutes then try re-running the user management in Okta. Set-MsolUserPrincipalName -UserPrincipalName [temp@yourdomain.onmicrosoft.com(mailto:temp@yourdomain.onmicrosoft.com)] -NewUserPrincipalName [Previous O365 Azure UPN] Original Author: Joel Hanson, Sales Engineer, OktaExpand Post
- PalakC.21412 (Customer)What is the App Assignment ID that is referenced here? and how can we retrieve that for every user?
- BillJ.27066 (Customer)
Exactly...I don't know why Okta support has this tendency to just give "answers" that just lead to more questions. Frustrating.
Hi @Palak and @Bill - I've escalated this case to our Support team, so we should get some clarity on this one shortly
- chris.hancock1.4756186399413728E12 (Okta, Inc.)
Hi Palak and Bill,
My name is Christopher Hancock and I am a support engineer at Okta. With regards to this question the original poster is referring to any unique value you define in the user assignment which will be mapped to the ImmutableID attribute in the O365 app.
When a user is Okta Mastered you will need to ensure there is a unique value being sent as the immutableID to O365, this immutableID is critical for federated users.
This can be done by editing the profile mappings for O365.
Admin --> Directory --> Profile Editor --> Office 365 (Mappings) --> Okta to Office 365 (Tab)
Then apply the following expression for the immutableID attribute: user.getinternalproperty("id")
This will send the users Okta UserID as the immutableID.
Alternatively you can use another value on the users profile, for example an employeeID however you would need to ensure these are unique for all users.
Hope the above helps,
Chris Hancock
Expand Post - BillJ.27066 (Customer)Hi Chris,
Thanks for the information. I do have one additional question. Should I have this set to be applied for creation only or on user create and update?
[cid:image001.png@01D50C7B.BCA8FDC0]
I’m assuming it should be set for user create and update, since it is pre-existing user accounts from Office 365 that are getting no immutableID value. I just don’t want to enable this and then potentially have everyone else’s O365 account get garbled.
Thanks,
BILL JOHNSON
SR. DESKTOP TECHNICIAN, INFORMATION TECHNOLOGYExpand Post - chris.hancock1.4756186399413728E12 (Okta, Inc.)
Hi Bill,
The recommendation is to set this as create only. If the value doesn't exist we will populate this once the mappings have been saved. I just ran a test in my application and confirmed the user was assigned with no immutableID, adding the expression below to the mappings updated this for the currently assigned user.
Additionally there was a small mistake with the expression I shared. This should be user.getInternalProperty("id")
Thanks,
Chris Hancock
Expand Post - BillJ.27066 (Customer)Hi Chris,
I think we are getting closer. The user is now reporting that his password is syncing. However, he now gets this error when he tries to use his Okta app for Office 365:
[cid:image001.png@01D50CB9.7E922E10]
Would you happen to know what could be causing this to happen or what to do to resolve it?
Thanks,
BILL JOHNSON
SR. DESKTOP TECHNICIAN, INFORMATION TECHNOLOGYExpand Post - chris.hancock1.4756186399413728E12 (Okta, Inc.)
Hi Bill,
Unfortunately the forum doesn't support images, would you be able to share the details of the error message, omitting any PII?
Otherwise it may be better to raise a support ticket so a support engineer can provide assistance on the issue as there looks to be a few issues that have been encountered and a remote session will be a more effective way to get the user up and running.
Thanks,
Chris
Expand Post
This question is closed.
