Okta MFA Credential Provider for Windows, version 1.3.8

This version of the agent contains bug fixes and security enhancements. See Okta MFA Credential Provider for Windows Version History.

Identity Governance

Okta Identity Governance is a SaaS-delivered, converged, and intuitive Identity and Access management platform. Use it to simplify and manage your identity and access lifecycles across multiple systems and improve the overall security of your company.

Use Okta Identity Governance solutions, such as Access Certifications, Access Requests, and Reports to:

• Efficiently create, protect, and audit access to critical resources.

• Improve your company’s security. Increase employee productivity.

• Improve IT efficiency by automating tasks to reduce the time taken and errors associated with manual data entry and provisioning tasks.

See Identity Governance.

Note that Okta Identity Governance is available to customers on a subscription basis. For more information, contact your Account Executive or Customer Success Manager.

Preview the token inline hook

Before implementing a token inline hook, you can now preview the hook request and the external-service response in the Admin Console. This feature aids in the development and testing of inline hooks before releasing to a production environment. See Preview an inline hook and Preview and test the token inline hook.

IE and Edge Legacy plugins

You can no longer download the Internet Explorer (IE) and Edge Legacy browser plugins from the Downloads page. These plugins aren't supported.

Improvements to the sign-in experience

When users create an account using the Sign Up link in the Sign-In Widget, they enter their first and family names along with their email address on the first page. The Sign-In Widget then displays the authenticators page, where users enter a password and configure any other mandatory authenticators. To streamline the sign-up process, the Self-Service Registration with Password feature allows you to show the password entry on the first page of the enrollment form instead. See Collect profile information and register users.

Manage embedded widget sign-in support

Okta provides the Okta Sign-In Widget out of the box so that customers can authenticate users by simply redirecting them to the widget. For customers who need a customized sign-in experience, Okta also provides a widget SDK that developers can embed within their applications. This embedded widget uses a custom authorization mode called the Interaction Code grant type to authenticate users. The Embedded widget sign-in support toggle allows super admins to disable the embedded sign-in option across all applications and authorization servers. This helps to create consistency and improves the security posture of your applications. See Configure embedded sign-in support.

Security enhancement of Okta Verify push notifications

To help users recognize and prevent phishing attacks, Okta Verify push notifications on mobile devices and Apple Watch include the name of the app to be accessed and the org URL.

ChromeOS as a device platform

You can now select ChromeOS as a device platform in authentication policy rules or identity provider routing rules. This enables you to configure how users access Okta-protected resources from ChromeOS devices. See Add an authentication policy rule and Configure identity provider routing rules

Authentication policy rules:

Identity provider routing rules:

Certificate chain builder for Smart Card IdP

Admins can now upload individual certificate files to build a certificate chain for a Smart Card IdP. This eliminates the requirement to manually create a file that contains the certificate chain. See Add a Smart Card Identity Provider.

Telephony usage report

The Telephony usage report displays data about an org’s telephony events over time. The report can be filtered by voice or SMS events and helps admins quickly understand usage trends and troubleshoot deliverability or request issues. See Telephony usage report.

Email deliverability events in the System Log

Admins can now view the following email deliverability event types in the System Log:

• Delivered
• Deferred
• Dropped
• Bounce

This helps admins better monitor the email deliverability activity in their org. See System Log.

Single sign-out changes for custom domains

If an admin signs out from a custom domain, their Admin domain and subdomain sessions now remain active. If they sign out from the Admin domain or subdomain, their custom domain session is ended.

People page improvements

People page filter results are improved as follows:

• Status > Password reset filter results now include users with both Password expired and Password reset status.

• Status > Active filter results return only users with an active status.

OKTA-508888

Some orgs were unable to configure their global session policies to display the password-first Sign-In Widget.

OKTA-509453

Staged and provisioned user accounts received different error messages when they clicked Forgot password? on the Sign-In Widget. This occurred in orgs with User Enumeration Prevention turned on.

OKTA-527215

Routing rules incorrectly redirected some users to an IdP before they could enter their username.

OKTA-532720

Some YubiKeys didn't work for authentication even though they were successfully enrolled.

OKTA-534595

Admins with a custom role couldn’t edit the users in a group if the group was assigned to an app with profile sourcing enabled.

OKTA-536037

When a DELETE request to the /api/v1/authorizationServers/<authServerID>/clients/<clientID>/tokens endpoint was called for large scale operations, an HTTP 500 error was returned.

OKTA-538402

Some admins weren't able to delete network zones after they upgraded to Identity Engine.

OKTA-541442

Errors during federation sometimes didn't display the cause of the error.

OKTA-542472

The authn_request_id information was missing from the user.authentication.auth_via_mfa System Log event for Okta Verify Push verifications.

OKTA-544783

The Norwegian translation of the end-user settings and preferences menu was incorrect.

OKTA-546310

Admin roles that were constrained to a group with group rules couldn't be assigned to a user or group.

OKTA-547525

The Welcome page, SMS reminder prompt, and security image prompt weren’t displayed for users accessing Okta using AD SSO in incognito mode.

OKTA-549174

After upgrading to Identity Engine, orgs with custom domains couldn’t use getRequestContext in the Sign-in page code editor.

OKTA-549537

The Box integration provisioning menu didn’t display the correct settings.

OKTA-549886

Using an Agentless DSSO test endpoint without any routing rules configured to use ADSSO resulted in a 404 error.

OKTA-550773

Some orgs didn’t correctly recognize a sign-in attempt using a smart card.

OKTA-550789

Provisioning new users from Okta to Office 365 failed.

OKTA-551130

The Email Authenticator challenge lifetime was sometimes set to five minutes regardless of its value in the authenticator settings.

OKTA-552637

Users were sometimes signed out of Okta right after signing in if the tokens returned were too large.

OKTA-552810

Customized sign-in pages for orgs using a custom domain didn’t render properly.

OKTA-553284

When the full-featured code editor was enabled, updates to email customizations, custom error pages, and the sign-in page didn't trigger System Log events.

OKTA-557858

Internet Explorer 11 users were blocked from signing in to orgs that used custom domains.

App Integration Fixes

The following SWA apps were not working correctly and are now fixed

• Chase (OKTA-549904)

• iAuditor (OKTA-549658)

• MeridianLink Consumer (OKTA-541626)

• Office 365 Dynamics (OKTA-549978)

• Quickbooks (OKTA-549905)

Okta AD Agent, version 3.13.0

This version of the agent contains the following changes:

• Health check of auto update service before auto update process is started
• Web proxy support for agent auto update feature
• Updated log category for existing logs from DEBUG to INFO
• Security fixes

See Okta Active Directory agent version history.

Okta RADIUS Server agent, version 2.17.7

This version of the agent contains security fixes and resolves a memory leak that occurred when agents were configured for EAP-TTLS. See Okta RADIUS Server Agent Version History.

Improvements to the self-service password reset experience

Previously, the self-service password reset (SSPR) flow created unnecessary friction in the user experience. The newly enhanced SSPR feature introduces a seamless magic link experience for password reset emails. Users no longer need to provide consent when using the same browser. After a successful password reset where the password meets the application’s assurance policy, the user is signed directly to the app. See Configure the Email authenticator. This feature is currently enabled by default for new orgs only.

Improvements to the self-service unlock process

Earlier versions of the self-service unlock (SSU) flow created unnecessary friction in the end user experience. The newly enhanced SSU feature introduces a seamless magic link experience in emails sent out to unlock accounts. Users no longer need to provide consent when using the same browser. In addition, after successfully unlocking their account, clicking the email magic link counts towards the application's assurance policy. After the assurance requirements are met, the user is signed directly in to the application. See Configure the Email authenticator. This feature is currently enabled by default for new orgs only.

New permissions for custom admin roles

Super admins can now assign these new permissions to their custom admin roles:

• Manage authorization server
• View authorization server
• Manage customizations
• View customizations

The authorization server permissions can be scoped to all or to a subset of the org’s authorization servers. With these new permissions, super admins can now create custom admin roles with more granular permissions for managing their org’s customizations and authorization servers. See About role permissions.

New HealthInsight tasks

Two new HealthInsight tasks help admins improve the security of their global session policies. HealthInsight now provides guidance for increasing the required authentication frequency for specific resources, and for requiring high-risk users to provide MFA every time they sign in. See Change the authentication frequency and Evaluate a risk score for each request.

Event hooks for consent revocation

Consent revocation events are now selectable for use with event hooks. See Add an event hook . See Event Types for a list of events that can be used with event hooks.

Agentless Desktop Single Sign-on

With Agentless Desktop Single Sign-on (DSSO), you don't need to deploy IWA agents in your Active Directory domains to implement DSSO functionality. This reduces or eliminates the maintenance overhead and provides high availability as Okta assumes responsibility for Kerberos validation. See Active Directory Desktop Single Sign-on.

Polling support for Agentless Desktop Single Sign-on and Integrated Windows Authentication sessions

Agentless Desktop Single Sign-on (ADSSO) and Integrated Windows Authentication (IWA) authentication sessions now include polling to reduce the likelihood of service disruptions during periods of high bandwidth use. For users authenticating with ADSSO or IWA during peak periods, this change increases the likelihood that a server will be available to process their authentication request. See Active Directory Desktop Single Sign-on.

Agentless Desktop Single Sign-on authentication progress updates

Agentless Desktop Single Sign-on (ADSSO) authentication progress pages have been updated to make authorization and verification progress more visible and improve the user experience. See Configure agentless Desktop Single Sign-on.

Password expiration settings for Active Directory

You can specify the password expiration policies for Active Directory for all preview organizations to set the maximum password age in days and the number of days before password expiration when the user receives a warning.

JIT users from Active Directory

Just-In-Time (JIT) provisioning enables automatic user account creation in Okta the first time a user authenticates with Active Directory (AD) delegated authentication, Lightweight Directory Access Protocol (LDAP) delegated authentication, or Desktop SSO. JIT account creation and activation only works for users who aren't already Okta users. This means that users who are confirmed on the import results page, regardless of whether or not they were subsequently activated, aren't eligible for JIT activation. When JIT is enabled, users don't receive activation emails. See Add and update users with Active Directory Just-In-Time provisioning and Add and update users with LDAP Just-In-Time provisioning.

Service Principal Name functionality improvement

New Service Principal Name (SPN) functionality allows Agentless Desktop Single Sign-on (ADSSO) authentication to continue without interruption when an SPN is updated. A service account and an SPN are required for ADSSO Kerberos authentication. With this change, you can now update the SPN frequently as an additional security precaution. See Create a service account and configure a Service Principal Name.

Enhanced Okta LDAP integrations with Universal Directory

Okta LDAP integrations now feature custom mapping, schema discovery, and a fully extensible attribute schema that allows you to import or update any attribute stored in LDAP. With these enhancements, Okta LDAP matches the schema functionality already available to Active Directory integrations. See Profile Editor.

OpenLDAP support for Auxiliary Object classes

You can now input a comma-separated list of auxiliary object classes when importing users from LDAP. See Configuring Your LDAP Settings.

New rate limits dashboard filter

You can now filter the APIs listed on the rate limits dashboard by their rate limit multiplier eligibility status. See Rate limit monitoring.

Eligible authenticators in Security Methods list

The Security Methods list on the Settings page now displays only those authenticators that a user may enroll in as determined by the configuration of the org's authenticator enrollment policy. This improves the user experience by ensuring that users are only presented with options that lead to successful authenticator enrollment.

ISV Portal email address updated

The email address for ISV Portal communications is now oanapp@okta.com.

Invalid phone numbers rejected

Okta now rejects attempts to enroll a toll-free, premium, fixed-line (SMS), or any other invalid or unrecognized phone number. This ensures that only valid phone numbers are used for multifactor authentication or device enrollment. See Configure and use telephony.

Enhancement to System Log event

The USER_AUTHENTICATION_AUTH_VIA_MFA System Log event has been enhanced. It now records the URL and IP address of a suspicious website and the mismatched origin header from the HTTP request when Okta detects and blocks a phishing attempt. This enhancement enables admins to track patterns of suspicious activity.

OKTA-476449

Admins could create resource sets that contained duplicate resources.

OKTA-512927

Two different Okta users could be linked to the same AD user through provisioning.

OKTA-515733

Users were sometimes signed out of Okta right after signing in if the tokens returned were too large.

OKTA-523330

Okta Provisioning Agent (x64 RPM) and Okta Provisioning Agent (Windows x64) were incorrectly swapped.

OKTA-526726

When admins deleted a property in an implicit app user schema, a property with the same name couldn't be recreated after the deletion.

OKTA-529966

Users couldn’t enroll a Voice Call Authentication (MFA) factor if Twilio was used as the provider and the phone number had a comma in its extension.

OKTA-530843

Parallel JIT requests for the same username created duplicate users.

OKTA-532898

A long text string was displayed outside of the General Settings page in OIN Manager.

OKTA-532900

The Enter your Post Logout Redirect URI field for OIDC settings in OIN Manager didn’t accept all valid URLs.

OKTA-533309

When signing in to a RADIUS app, users were sometimes shown the incorrect operating system in Okta Verify push messages.

OKTA-533753

Admins couldn’t add more than 10 translations of a customized email template.

OKTA-533897

Google background service users received unrequested Okta Verify Push notifications.

OKTA-544628

Some orgs experienced internal server errors during outbound SAML federation.