The initial user provisioning push for new user creation in the Microsoft Office 365 Okta Integration Network (OIN) app and/or the Microsoft Office 365 GCC High OIN app fails with a Microsoft Graph Application Programming Interface (API) error that is mentioned below despite the Microsoft Office 365 app itself having WS-Federation Single Sign-On (SSO) configured under the Sign On tab and Sync Password is also disabled under the To App page.

The specified password does not comply with password complexity requirements. Please provide a different password.

 
This article will explain the observed behavior and how to fix the initial app assignment provisioning error.

• Microsoft Office 365 OIN app and/or Microsoft Office 365 Government - GCC High OIN app
• Okta Integration Network
• WS-Federation SSO configured
• Provisioning feature Sync Password is disabled
• Okta Classic Engine
• Okta Identity Engine (OIE)

Microsoft Entra ID (including GCC High) requires a password to be defined in the passwordProfile property when a new user is created via the Microsoft Graph API, which is what Okta uses for Profile Sync provisioning method. Even if the user is intended to be Federated (meaning they will eventually log in via Okta without a Microsoft password), the initial "Create User" System for Cross-domain Identity Management (SCIM) user provisioning request initiated from Okta to Microsoft must include a temporary password that meets the Microsoft tenant's password complexity requirements.

The error happens because:

• Mandatory Attribute: The passwordProfile is a mandatory object for the POST https://graph.microsoft.com/v1.0/users endpoint in the Microsoft Graph API.
• Okta's Role: When Okta provisions a new user to Office 365, it generates a random temporary password (based on the Okta user's applied Okta password policy configuration settings) to satisfy Microsoft’s API requirement.
• The Conflict: If the customer's Microsoft O365/Microsoft O365 GCC High tenant has extremely high password complexity settings (common in government environments) or if there is a Conditional Access/Password Policy blocking the specific type of password Okta is sending, Microsoft rejects the account creation entirely when Okta sends the Microsoft Graph API call.

Key Clarifications for GCC High

• Federation doesn't skip the "Create" requirements: Even though the Microsoft-verified domain is federated and users won't use a Microsoft password, Microsoft still validates the password sent during the initial Okta/O365/O365 GCC High user provisioning push for the new user creation step.
• Sync Password vs. Initial Password: While the Sync Password feature in Okta's Mirosoft Office 365 OIN app Provisioning > To App page (which keeps passwords in sync after initial Microsoft user creation) might be disabled as recommended in the Possibility to Enable Password Sync for a Federated Microsoft Office 365 Integration documentation for Federated domain users, Okta still must send an initial password to create the new Micrososft Entra ID user object in Micrososft tenant environment for brand new Micrososft Office 365 app assignment's initial user provisioning task.

To summarize, Okta always sends a randomly generated password when provisioning a new user to Microsoft Office 365 /GCC High, regardless of whether the Sync Password feature is enabled or disabled; these are two completely separate processes. Disabling Sync Password only stops Okta from pushing ongoing password changes to the app; it does not affect the initial user creation.

Similarly, having WS-Federation SSO configured with a verified federated domain does not prevent Okta from sending a password during user creation; Okta does not check the federation status before sending the password to Microsoft. The temporary password Okta randomly generates is based on the Okta password policy assigned to that impacted end user.

To troubleshoot/mitigate the initial app assignment/provisioning task failure: 

1. Check "Sync Password": Ensure the Sync Password option under Provisioning > To App is actually disabled. This is mandatory, as explained in the Possibility to Enable Password Sync for a Federated Microsoft Office 365 Integration documentation.
2. Verify Domain Federation: Confirm that the problematic app user's domain is fully verified as "Federated" in the Microsoft Entra ID portal. If Microsoft thinks the domain is "Managed," it will strictly enforce password policies.
3. Cross-compare Okta vs. Microsoft Tenant's Password Policies/Password Complexity requirement: With help from a Microsoft Administrator, check on the current Microsoft Tenant/Microsoft GCC High Tenant's password complexity requirement vs. Okta Password Policies' password complexity requirement.

• • Ultimately, the Okta Password Policies must have equal or stronger password complexity requirements than Microsoft Tenant's password complexity requirements to avoid failing the Microsoft password condition check during Okta/O365's initial provisioning/app assignment failed tasks. 

NOTE: Admins should always run lower environment tests before applying any direct configuration change to the Production org. For admins without a lower environment setup, it is recommended to create a small subset of test users in the Production org and run a controlled user test before applying any changes to all active Production org users in bulk. 

4. Retry Failed Task from Okta Admin Console: After reviewing and applying any of the above necessary recommended solution steps, presuming any necessary changes to the password policy in the Okta org instance or Microsoft Tenant have been made, navigate to Dashboard > Tasks in Okta and retry the failed assignment for the previously impacted users.

   • As long as the randomly generated initial password sent by Okta that meets the targeted Microsoft tenant's password complexity requirement is included for the Microsoft Graph API during the POST https://graph.microsoft.com/v1.0/users during initial app assignment + initial app provisioning with a new external Microsoft user creation job, the retried failed task should be completed without the previous Microsoft password complexity requirement not met error.