Azure Provisioning broken: GUID on Oracle SaaS changes due to user import from another source

Question

Azure Provisioning broken: GUID on Oracle SaaS changes due to user import from another source

FGable 20

Azure is provisioning a 2 AD attributes to our Oracle SaaS via the SCIM call

The "target" SaaS gets refreshed with data/user accounts from another "source" SaaS (DEV/TEST/QA/UAT).

Oracle SaaS LDAP contains a GUID for the users. Azure somehow knows this GUID.

The GUID in the "target" SaaS changes to the value from the "source" environment and Azure claims it cannot find the account to provision.

I can call the SCIM API of the "target" and see the GUI has changed for the user

I can confirm via the Azure provision logs that Azure is looking for the old GUID

I have stop/started/restarted provisioning. Removed the user from the SaaS side, removed the user from the Azure ACL list and rebuilt provisioning to try and clear the Azure cached GUID.

Any other thoughts of how to clear the cached Azure GUID?

Thanks

FGable 20 Reputation points

2023-03-29T11:57:39.0966667+00:00

Thanks @Anonymous

Is {servicePrincipalId} and {jobId} the same as my applications "Application ID" and "Object ID" shown on the Application Overview properties in Azure?
Danny Zollner 10,831 Reputation points Microsoft Employee Moderator

2023-03-29T16:29:20.6066667+00:00

Service Principal ID is the objectId of the app. JobID can be found on the provisioning panel of the app on the main provisioning splash screen under the Technical Information dropdown (I think that's the label..). It's also discoverable via MS Graph - https://learn.microsoft.com/en-us/graph/api/resources/synchronization-overview?view=graph-rest-beta#list-existing-synchronization-jobs and is in the format of "SfSandboxOutDelta.e4bbf44533ea4eabb17027f3a92e92aa" - either two or three sections, one of which is going to say either "scim" or "oracle" or something of the sort, and the other sections being GUIDs representing the application and the AAD tenant ID.

Answer accepted by question author

0 additional answers

Your answer

FGable 20 Reputation points

2023-03-29T11:57:39.0966667+00:00

Thanks @Anonymous

Is {servicePrincipalId} and {jobId} the same as my applications "Application ID" and "Object ID" shown on the Application Overview properties in Azure?
Danny Zollner 10,831 Reputation points Microsoft Employee Moderator

2023-03-29T16:29:20.6066667+00:00

Service Principal ID is the objectId of the app. JobID can be found on the provisioning panel of the app on the main provisioning splash screen under the Technical Information dropdown (I think that's the label..). It's also discoverable via MS Graph - https://learn.microsoft.com/en-us/graph/api/resources/synchronization-overview?view=graph-rest-beta#list-existing-synchronization-jobs and is in the format of "SfSandboxOutDelta.e4bbf44533ea4eabb17027f3a92e92aa" - either two or three sections, one of which is going to say either "scim" or "oracle" or something of the sort, and the other sections being GUIDs representing the application and the AAD tenant ID.

Answer 1

https://learn.microsoft.com/en-us/graph/api/synchronization-synchronizationjob-restart?view=graph-rest-beta&tabs=http

That restart API call with a resetScope value of "Full" will do the trick. This will flush the links between source(AAD) and target (Oracle/SCIM) objects. This can only be done for the entire job, not for specific objects.

FWIW, AAD Provisioning expects that it is the primary source/authoritory for the objects it is managing in a connected SCIM app. It sounds like this problem is happening as a result of refreshing dev/test environment data with more accurate data based on some other environment such as prod. If this is also happening in prod then it's likely that some business process manipulating data in the SCIM app is flawed and should be adjusted.

Share via

Azure Provisioning broken: GUID on Oracle SaaS changes due to user import from another source

0 additional answers

Your answer