This article provides guidance on resolving a specific error encountered during the Single Sign-On (SSO) flow between Okta and Microsoft Office 365. The error message reads:

AADSTS51004: The user account <id> does not exist in the <id> directory. To sign in to this application, the account must be added to the directory.

• Administrators working with Microsoft Office 365
• Federation (WS-FED)
• Single Sign On (SSO)

This error arises when a Microsoft Office 365 user has an ImmutableID in Entra ID that does not match the ImmutableID configured in Okta.

Verify ImmutableID in Entra ID

1. Open Windows PowerShell.
2. Connect to Microsoft Graph using the command: Connect-MgGraph -Scopes Directory.AccessAsUser.All.

NOTE: Microsoft Graph will need to be installed if it has not already been installed. For more information, please check the Microsoft Documentation: Install the Microsoft Graph PowerShell SDK documentation. 

3. Verify if the ImmutableID is missing for the affected user by running the following command (replace <user@domain.tld> with the user's UPN):

Get-MgUser -UserId <user@domain.tld> -Property OnPremisesImmutableId | Format-List OnPremisesImmutableId. 

A blank value indicates that the ImmutableID is missing.

Solution 1: ImmutableID is available in Okta, but is missing in Entra ID

Set the ImmutableID for the affected user with the following command (replace <user@domain.tld> with the user's UPN and <ImmutableId> with the new ImmutableId):

Update-MgUser -UserId user1.test0000@secura.one -OnPremisesImmutableId <ImmutableId>

Solution 2: ImmutableID is available in Entra ID, and Active Directory is used in Okta

If Active Directory is used, check the mappings and verify if the value is populated by Active Directory.
In the Okta Admin Dashboard > Profile Editor > Office 365 instance > Mappings > Okta > Office 365.
The following expression can be seen:

hasDirectoryUser()?findDirectoryUser().externalId:null

Solution 3: ImmutableID is available in Entra ID, and Active Directory is not used in Okta

In this scenario, Active Directory is not used as a source, and Okta is not mapping the Object GUID (external ID) to the ImmutableID.
Best practices recommend that the Okta User ID be used as the mapping value for the ImmutableID, as the Okta User ID is an immutable value during the user's lifecycle.
Mappings will have to be adjusted accordingly with the following expression:

user.getInternalProperty("id")

Related References

• Set-MsolUserPrincipalName
• Matching on premises user to cloud user
• Microsoft Documentation: Install the Microsoft Graph PowerShell SDK