Microsoft Entra SaaS Connector – Provisioning Users to a Federated Domain issues

[Palvag (Patrik Alvaag)]

Hi everyone,

We’re currently testing an architecture where Okta acts as the primary IdP for Microsoft Entra ID, while SailPoint ISC handles identity lifecycle management and account provisioning.

Our intended setup is:

HR → SailPoint ISC → Okta + Microsoft Entra ID (federated with Okta)

We’re using the Microsoft Entra SaaS connector to provision standard member accounts (not B2B guest users).

Provisioning users into a non-federated (managed) domain works without any issues. However, we’re unable to create users in a domain federated with Okta.

Issue 1 - immutableId is always sent as Boolean false

Microsoft Entra requires a SourceAnchor when creating a user in a federated domain.

We added immutableId to the Create Account provisioning policy, but regardless of the configured value, the Account Activity shows:

Add immutableId: false

Microsoft Graph then returns:

400 Request_BadRequest: Cannot convert the literal 'False' to the expected type 'Edm.String'.

We’ve tested both:

• A static value (GUID)

• A populated SailPoint identity attribute containing a Base64-encoded Immutable ID

Both result in immutableId: false.

Issue 2 – isFederatedDomain is missing

According to the SailPoint documentation, isFederatedDomain should be available in the Create Account provisioning policy.

However, this attribute was not available in our source.

We manually added it in the Create Account policy.

We tested it with a static value of true, using both String and Boolean field types.

Unfortunately, account creation then fails with:

404 Request_ResourceNotFound: Resource '' does not exist or one of its queried reference-property objects are not present.

When we disable both immutableId and isFederatedDomain, the error changes to:

400 Request_BadRequest: SourceAnchor is a required property for creation of a federated user.

Troubleshooting performed

• Confirmed successful provisioning into a managed domain using the same Entra source.

• Confirmed that the SailPoint identity has a populated Immutable ID.

• Tested static and identity-attribute mappings for immutableId.

• Tested isFederatedDomain as both String and Boolean.

• Reviewed the Create Account policy and source configuration through the SailPoint API.

• Tested the skipEncodingImmutableID setting without resolving the issue.

Questions

1. Has anyone successfully provisioned standard member accounts into a federated Entra domain using the Microsoft Entra SaaS connector?

2. Why might immutableId be evaluated as Boolean false even when configured with a static string?

3. Should isFederatedDomain be available by default in the Create Account policy? If not, how should it be configured?

4. Is there any additional configuration required for provisioning cloud-only accounts into an Entra domain federated with Okta?

5. Could this be a limitation or issue specific to the SaaS connector?

I found a similar discussion, but that thread is closed for replies.

I’ve also opened a SailPoint Support case, but wanted to check whether anyone in the community has experience with this setup.

Any suggestions would be greatly appreciated.

Thanks!

[punna0001 (harish Punna)]

Hello Patrik. I would suggest checking the SaaS connector’s supported operations before making further changes to the provisioning policy. There is a contradiction in SailPoint’s documentation. The Supported Features and Create Profile Policy describe federated-user creation, but the SaaS operation matrix lists Create = No for federated-domain users.

For your errors, I would narrow it down this way:

1. immutableId: false: Since both your static GUID and populated identity attribute resolve to false, I would compare the resolved Create provisioning plan with the connector’s outgoing request. If the plan already contains false, investigate policy evaluation and plan construction. If the plan contains the correct String but the connector sends false, that points toward connector handling. Support may need to trace this.
2. Missing isFederatedDomain: The SaaS documentation lists it as a Static field set to true, but does not list immutableId separately. The VA-based Create Policy documents both. I would ask Support whether your SaaS policy template is correct and whether manually adding these fields is supported.
3. 404 error: I would check which Graph operation returns Resource '' does not exist before assuming the cause. The SourceAnchor is required error when both fields are disabled is expected.

For your cloud-only Okta setup, make sure onPremisesImmutableId matches the anchor expected by your Okta federation mapping. A random value may allow account creation but will not necessarily work for authentication. You could also test one disposable user directly through Graph and compare the request with the connector’s behavior.

There is a similar community case where isFederatedDomain=true and an Okta UID mapping worked, although the connector type was not confirmed. The VA-based Entra connector lists Create = Yes for federated users, but Update, Delete, and Enable/Disable remain unsupported.

Since you already have a Support case, I would specifically ask them to confirm SaaS federated Create support and identify where your static immutableId changes to Boolean false. Those two answers should help determine whether this is a configuration issue or a connector limitation.