HR-> SailPoint ISC to Okta and EntraID (federated with Okta)

Identity Security Cloud (ISC) ISC Discussion and Questions
1

We’ve been struggling to get our new joiner orchestration in place.
The high level architecture looks like this:
-Daily HR feed in SailPoint ISC
-Role setup in ISC that includes AzureAD license group, and AzureAD Account creation
-Okta will also be provisioned by SailPoint, in the future. Right now, there is an Okta workflow that creates users daily, from a similar HR Feed.
-EntraID will be federated for SSO with Okta.

We’re running into some problems with this setup:

  1. SailPoint was able to successfully create AAD accounts for users, before SSO federation was enabled.
  2. After turning on federation for a small domain, Okta sign-in fails for accounts, pointing to issues with the immutableid - not sure if this is the issue, or a side effect of some hidden issue.
  3. SailPoint fails to provision new accounts with an error that reads: sailpoint.connector.ConnectorException: Exception occurred. Error message - HTTP not ended OK. Response Code - 400 Error - SourceAnchor is a required property for creation of a federated user.
  4. I tried to map the OKTA account ID to the AzureAD ImmutableID at account creation and attribute sync, but this fails.
    Not using IQ Services for AZURE AD for the time being.

We’ve also been in countless calls with Okta support, MS support, no luck so far.
I’m hoping someone here has a similar setup and can spot something in my blindside.

2

I think it’s to do with the user profile mapping of where the immutable ID is mapped from.

See this:
https://support.okta.com/help/s/article/handling-immutable-id-issues-in-okta-for-microsoft-365-assignments?language=en_US

There’s an OOTB expression…vs a recommended / documented expression. You may need to update the value(s) on MS side if it concerns multiple users.

…and this:
https://support.okta.com/help/s/article/ms-o365-federation-immutableid-missing-issue-with-o365-federation?language=en_US

3

Wow,
Thanks, this is a good hint and a point in the right direction.
This could solve the issue for existing users.

Now for newly created users, I am not sure how I could get the Okta app id value, I guess that is not the unique Okta user account id.
I was trying to user ISC Create User by mapping the immutable id to the value that the okta account has.
This resulted in the MS account not being created and getting the above 400 error.

Best Regards,
Raul Sabau

Classified as C2 - General Business

4

Ok, after a lot of tinkering here is the solution I’ve found.
This was probably failing because I had set the isFederatedDomain to disabled.
This needs to be false or true.

With it being set to true, and the immutableID value set to an identity attribute that was mapped to the Okta account UID of the person, this worked.
The Okta Account UID is unique across the domain, so it works in our case.

1 Like
5

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.