M365 App Federation: "Account not configured" error, even with "Okta Username" format

Questions
1

Hello, Developer Community.

I’ve encountered some unexpected behavior during a cloud-only Okta-Azure AD (Entra ID) federation test and would like to understand why my solution worked.

Scenario:

  • Environment & Goal: We are using Okta as the IdP (for Authentication) and Azure AD (for Authorization), with the goal of signing into the Azure Portal. (This is a cloud-only environment, with no on-prem AD).

  • Okta User: Created in Okta (user.login is test.user1@domain.com). This user’s “Immutable ID” field (in the Okta profile) was originally null (empty).

  • Azure AD User: Created in Azure AD (UserPrincipalName is test.user1@domain.com).

  • Azure AD OnPremisesImmutableId: Successfully set via PowerShell to the plain string test.user1@domain.com.

Okta App Configuration:

  • Microsoft Office 365 app (using WS-Federation).

  • Application username format: “Okta Username” (This is the key point I want to confirm).

The Error:

When a user tried to sign in, Okta authentication (password/MFA) succeeded. However, Okta then displayed the error: "Office 365 login failed. This application does not have an account configured for you."

The Surprising Fix:

I fixed this by editing the Okta user’s profile (test.user1@domain.com) and manually setting the “Immutable ID” field (which was blank) to the string test.user1@domain.com.

After this change, the login succeeded. Okta correctly sent test.user1@domain.com as the ImmutableId, which matched the value in Azure AD.

My Question:

Why was this manual step (populating the Okta “Immutable ID” field) necessary?

I assumed that setting the “Application username format” to “Okta Username” would tell the app to simply use the user.login value (test.user1@domain.com) as the ImmutableId to send to Azure.

Why did the M365 app integration also seem to require the Okta user’s “Immutable ID” field to be populated? Does the O365 app have a special behavior where it prioritizes the Okta “Immutable ID” field (which is normally for objectGUID) even if the username format is set to “Okta Username”?

Thanks for any insights.

2

It sounds like you may want to update the Profile Mappings from the Okta Profile to the Office 365 profile to ensure that the user’s email/username (whichever is appropriate) is mapped into the Immutable ID field for Office 365