Limitations

The following Classic Engine features in the Admin Console have changed or are no longer supported in Identity Engine

Are you a developer? See the Okta Identity Engine Limitations for developers.

Feature changes

Active Endpoint

Identity Engine doesn't support Just-In-Time (JIT) provisioning on Active Endpoint (also known as Exchange ActiveSync auth or legacy auth).

  • JIT user creation: Importing a user that doesn’t exist in Okta on-demand from an on-premises Active Directory (AD) or Lightweight Directory Access Protocol (LDAP) directory during the authentication.

  • Reactivation: Reactivating an inactive or suspended user on-demand when that user is marked as active in an on-premises AD or LDAP directory.

  • Profile refresh: Calling the AD Agent or LDAP Agent to read the user’s latest profile attributes into Okta from the on-premises directory during the authentication.

Identity Engine end users should sign in first through the browser or a newer MSFT client.

Office 365 sign-on rules options

Admin-initiated WebAuthn enrollment

Admins can’t enroll a WebAuthn security key on behalf of the end user through the Admin Console.

Configure Security Key or Biometric authenticator

App condition for MFA enrollment policy

Admins can’t target MFA enrollment policies to specific applications. Okta evaluates the MFA enrollment policy every time a user signs in to Okta, and prompts user to enroll in required authenticators.

About MFA enrollment policies and rules

Automatically select the user's last used MFA authentication method

When end users sign in to Okta and have multiple authentication methods to select from, Okta displays all available options. Okta no longer remembers some of the user’s last used authentication method.

Custom login page for embedded app links

Identity Engine doesn't support using a custom login page for embedded app links. Users who click an app embed link are now evaluated by their org’s global session policy. Admins can customize an Okta-hosted sign-in page or configure an IdP routing rule for the app.

Identity Provider routing rules and Configure a custom Okta-hosted sign-in page

Custom password expiration management

Identity Engine doesn't support the ability to display a custom message in the Sign-In Widget and a redirect URL when users' DelAuth passwords expires.

Configure general customization settings

Custom User Agent

App sign-on policy rules with a Custom User Agent (as client application) don't migrate fully. The Custom User Agent is lost after migration.

Allow or deny custom clients in Office 365 sign on policy

Don't prompt me again on this device

The Don’t prompt me again on this device checkbox for MFA authenticators is no longer present. Instead, this behavior occurs when the user selects the Keep Me Signed In checkbox.

Expiry time of email links

In Classic Engine, the default expiration time of email links used for self-service password resets, self-service account unlock, and multifactor authentication is one hour. You can configure their lifetime to last several days.

In Identity Engine, the default expiration time is five minutes and it’s configured as an authenticator. You can select expiry times in five-minute increments up to 30 minutes. This limit was set because user-initiated password recovery has the same security implications as authentication.

When orgs upgrade, their email link expiry settings change to the default settings in Identity Engine.

Integrated Windows Authentication

Identity Engine doesn't support Integrated Windows Authentication Desktop Single Sign-On. Orgs must use agentless Desktop Single Sign-on instead.

Migrate from Integrated Windows Authentication to agentless Desktop Single Sign-on

Link directly to self-service password reset or unlock pages

Admins can no longer provide a URL to link users directly to self-service password reset or account unlock. Users must go to the sign-in page and follow the links from there.

MFA Factor sequencing

Identity Engine doesn't support he ability to construct factor chains in Okta sign-on policies. Instead, you might be able to use passwordless authentication.

Configure Okta FastPass and Set up passwordless sign-in experience.

Okta Mobile

End users can't use Okta Mobile to access their apps. When users open Okta Mobile, this message appears: This organization is not supported on Okta Mobile. You can access your apps dashboard from your browser. You can also open the dashboard from the Okta Verify app.

Okta Mobility Management

Identity Engine doesn't support Okta Mobility Management.

Use Okta FastPass.

Pass Claim for MFA

Org-level MFA requirements don’t meet the Identity Engine requirement to pass a claim for MFA. Customers need to set up app sign-on rules for MFA.

Use Okta MFA to satisfy Azure AD MFA requirements for Office 365

Pass Claim for MFA Infinite Loop

Pass claim for MFA requires true MFA (one knowledge factor plus one possession factor). If users enter an infinite loop because they don’t complete MFA during the SSO flow, they should refresh and sign in with a different browser. Admins should review their authentication policy to ensure that it contains an MFA-related rule.

Use Okta MFA to satisfy Azure AD MFA requirements for Office 365

Password policies can override MFA enrollment policy settings

If a password policy allows users to perform self-service recovery with email, phone, or security question authenticators, Okta prompts users to enroll when they sign in. Okta prompts users to enroll even if these authenticators are disabled in the MFA enrollment policy. Email and security question authenticators are required if they’re configured in the password policy rules for recovery. Phone is optional.

About MFA enrollment policies and rules

Phone rollback behavior

If Phone is enrolled as an authenticator and admins roll back to the Classic Engine, both SMS and Voice are available for authentication.

RADIUS Legacy Model

Identity Engine doesn't support the RADIUS Legacy Model.

RADIUS Legacy Model

Registration hooks

In the Admin Console, the enablement of a registration inline hook has changed from the former Self-Service Registration page (Self-service Directory > Self-Service Registration) to the Profile Enrollment Rules page (Security > Profile Enrollment). The creation of the registration inline hook remains the same. You can create hooks in the Admin Console or by inline hook management APIs.

Existing registration inline hooks can experience compatibility issues after migrating to Identity Engine due to changes in the Okta registration inline hook request. Your application may require code updates to properly consume the new request format.

Profile enrollment

Remember Me

The Remember Me checkbox has been replaced with a checkbox that allows the user to remain signed in.

General security

Security Image

Identity Engine doesn't support the ability for end users to specify a security image when they first register for an account. Existing users who already registered a security image don’t see that image when they sign in.

Security Questions

Answers to security questions must have at least four characters. Currently, admins can't set the minimum length of answers. However, if your org upgrades with a minimum answer length set at fewer than four characters, that minimum is applied after the upgrade.

Self-Service Registration

Self-Service Registration is now accomplished through a profile enrollment policy. In a profile enrollment policy, admins select the attributes they want to collect when a new end user clicks Sign up. By the time the end user has authenticated into the app, their profile is complete and they’re provisioned to the appropriate groups.

Self-service registration

Sign out of Okta O365

Identity Engine doesn't support Sign out of Okta O365. There’s no work-around. The long-term solution is to have Single Logout capability across OpenID Connect, SAML, and WS-Fed. This feature has low adoption.

Suspicious Activity report

The Suspicious Activity report isn't available in Identity Engine.