Idaptive release notes

Release 20.4 (available September 25, 2020) introduces the following changes .

New features

New UI

This release introduces UI changes is to enhance usability and create a consistent user experience across all CyberArk products.

Global changes

  • Changed Terms of Use and Privacy Policy links to point to CyberArk’s Terms of Use and Privacy Policy.

  • Changed Copyright info to CyberArk Software Ltd.

  • Made branding-related layout and style updates throughout all UIs.

    User Portal and Admin Portal

  • User Portal navigation moved from top navigation to left navigation.

  • Moved the Switch to link from the username menu to a product tile menu in the left navigation.

  • Moved the product documentation link to the bottom of the left nav.

User Behavior Analytics Portal

  • Moved the username display to the top right for consistency with the User Portal and Admin Portal.

  • Added a product documentation link in the bottom of the left nav.

  • Moved Sign Out link from the left nav to the username menu in the top right.

  • Moved Copyright and build info to the username menu.


Idaptive product and developer documentation moved to the domain to make content easier to find, while changing the look and feel to create a cohesive user experience across CyberArk's documentation set.

Directory services

Support for Azure Active Directory

You can now add Azure Active Directory (AAD) as a directory source in the Admin Portal.

If you are using Microsoft Azure Active Directory (AAD) to store and manage your user information, you can configure Idaptive Identity Service to recognize it as a directory service and see the users as managed domain users. You can then add your AAD users to roles and grant permissions to access applications. Your users can then log in to Idaptive Identity Service with their AAD accounts and launch assigned applications.

Idaptive Identity Service currently supports only managed domains for a single instance of Azure Active Directory. Adding multiple Azure Active Directories might have unpredictable results and is not supported.

Refer to How to add a directory service for more information.

Improvements and behavior changes

General platform

  • The URL suffix for tenants configured to use a custom tenant URL as the Default URL changes to idaptive .app if it was still using

    For example, if you created a custom URL in Settings > Customization > Tenant URLs when the tenant was on the Centrify podscape and made it the Default URL, the URL suffix changes to (for example,

  • Replaced the following deprecated headers to reflect appropriate branding.

    Although deprecated headers currently remain functional for backward compatibility , we recommend changing to the new headers as soon as possible to ensure future compatibility.

    Deprecated header New header
  • Deprecated the following APIs:

    Deprecated API Replacement API
    /Oath/CentrifyOathOtpProfileCheck /Oath/CloudOathOtpProfileCheck
    /Oath/ResetCentrifyOathProfile /Oath/ResetCloudOathProfile

Adaptive multi-factor authentication

  • Users’ risk level is shown on the Users page in the Admin Portal , making it easy to identify risk y users.

    Refer to View user risk levels for more information.

  • SecurityAlert events now include the session_id to assist in reviewing security alerts.

    You can cross reference the value for session_id in a webhook alert against the value for InternalSessionId in Admin Portal reports or your SIEM environment.

Lifecycle management

Added support for inbound provisioning of the following UltiPro attributes:

  • JobDescription
  • CompanyName
  • JobTitle
  • DateOfBirth
  • PreferredName

Refer to Inbound Provisioning from UltiPro for more information.

Single Sign-On

  • IE and Safari 11 browser extensions are deprecated and no longer available from the Downloads page in the Admin Portal.

Fixed issues

General platform

Restricted usage of the /Core/SetTenantConfig API to prevent mis-configured tenants. This API will be made unavailable in a future release.

Component versions

This release includes the following components:



Windows Cloud Agent


Mac Cloud Agent


Android client


iOS client


Browser Extensions




Browser support

This version of Idaptive Identity Services has been tested with the following browsers:



Internet Explorer

Version 11 on Windows 2008 server, Windows 2012 server, Windows 7, and Windows 8

Microsoft Edge

latest version available at release

Mozilla Firefox

latest version available at release

Google Chrome

latest version available at release

Apple Safari


For silent authentication to work correctly, some web browsers need additional configuration (see How to configure browsers for silent authentication) or a browser extension (see How to install the Idaptive Identity Service Browser Extension).

On devices, the Idaptive application and Idaptive for KNOX open the web applications in the native browser unless that application requires a browser extension to provide single sign-on. For these applications only, the Idaptive application and Idaptive for KNOX open the application in its built-in browser.

Browser Extension support

The Browser Extension for Internet Explorer and Safari is deprecated. If your users use those browsers with a previous version of the Browser Extension and you want them to continue to do so, you should restrict updates to the Browser Extension.

Users restricted to old versions of the Browser Extension will not benefit from updates and new features.Refer to Restricting Browser Extension updates for more information.

Computers must meet the following requirements to install the Browser Extension.

  • Microsoft .NET Framework 4.6.2 or later
  • Microsoft Installer 3.1 or later

In addition, browser support for the Browser Extension features is indicated in the following table.

(latest available at release)
(latest available at release)
Form filling Yes Yes


App capture Not supported Yes

Not supported

Land and Catch Yes Yes


App Launch Yes Yes


Device support

If you are using Idaptive Identity Services for mobile device management and authentication, it supports enrolling the following devices and computers using the cloud agents:

Operating System

Versions supported


10, Server 2016, Server 2019


10.13, 10.14, 10.15


11.x, 12.x, 13.x

Devices using iOS 10 can still be enrolled and will be supported, but you cannot update the Idaptive Identity Services client beyond version 19.518.3.




5.0 or later

Samsung KNOX Enterprise SDK

3.x or later

This includes transparent integration with the Samsung Universal Mobile device Management Client (UMC) and the Samsung Enterprise Gateway.

Language support

Foreign language support is provided for the following components:

  • Idaptive Identity Services user portal help -- Japanese only
  • User portal text strings.
  • Admin Portal text strings

Not all of the languages listed below are available for the Admin Portal text strings.

Administrators can select the language in which the user portal texts and Idaptive Identity Services system messages are displayed. The default setting, (--), is equivalent to not setting a language. In this case, the user's browser language selection will be used. However, if users configure their own language selection, then that language takes precedence. For example, if you set the language to French in the Admin Portal and a user sets the language to Vietnamese in the User Portal, then Vietnamese is used for that user. Users can specify their language selection in User Portal > Account > Personal Profile > Language drop-down list.

To configure the language option in the Admin Portal

  1. Log-in to the Admin Portal.
  2. Click Access > Policies > Select the relevant policy.
  3. Click User Security Policies > User Account Settings.
  4. Select the default language in the Default Language drop-down list.
  5. Click Save.

In this release, translations are provided for the following languages:

  • Arabic
  • Brazilian Portuguese
  • Chinese—Simplified and Traditional
  • Dutch
  • French
  • German
  • Italian
  • Japanese
  • Korean
  • Portuguese
  • Russian
  • Serbian
  • Spanish
  • Swedish
  • Thai
  • Vietnamese

Additional languages are being added over time—see the Release Notes for the most recent additions.

Known Issues

Directory services

User Portal > Account > Personal Profile is read-only for Google Directory Service, LDAP, and Federated Directory users due to an issue with saving additional attributes.

Multi-Factor Authentication

FIDO2 or on-device authenticators require logging in from your tenant-specific url.

Windows Cloud Agent

  • The grace period functionality is not implemented for Windows machines not joined to a domain.

  • If AD user tries to login to a WCA-enrolled domain-joined Windows device for the first time when the domain is unreachable; MFA works; however, a new local user gets created and gets mapped to that AD user.

    But after the first login, when the AD user tries to login again even when the domain is reachable, the user will still be logged in as local user mapped to an AD user (just like it works for a non-domain joined device). In such a case, native Windows functionality like iWA or Kerberos will not work for that user, even if machine is domain joined and domain is reachable.

    Workaround: The domain should be reachable when an AD user tries to login to the system for the first time

  • The user’s browser might not automatically select the certificate for certificate-based authentication on enrolled machines.

    Workaround: Users can manually select the certificate in the pop-up window.

  • The MFA login screen shows “Phone Call” more than once if user has multiple phone numbers configured.

  • LDAP is not currently supported as a user directory for the Windows Cloud Agent.

  • The Windows Cloud Agent currently only supports AD-joined endpoints.

  • With RDP (v 6.0+), a user cannot RDP to the endpoint/server with the Windows Cloud Agent using an Idaptive directory user. This is because the network credential validation is done on the client side first, before establishing the remote desktop connection.


  • Windows Cloud Agent does not currently support MDM enrollment. As a result, certificate-based authentication (ZSO) doesn't work on enrolled Windows workstations, unless they are manually enrolled onto MDM.

  • Windows Defender SmartScreen might show a warning when installing the Windows Cloud Agent. This happens because the Windows Cloud Agent is new and not yet on the list of safe files that Windows Defender SmartScreen checks.

Mac Cloud Agent

  • Certificate-based authentication is not functional on Mac Cloud Agent enrolled Macs.

    Workaround: Users can sign in to Idaptive services manually.

  • The Mac Cloud Agent cannot be updated from the UI.

    WorkAround1 : Go to the user portal or admin portal to download the latest agent.

    Workaround 2: Click the Update button on the top menu, then click latest agent version. When you see the message "Failed to connect to launch...", click OK, then close the application.

    Reopen the Mac Cloud Agent and note the agent is updated to the latest version.

  • Self-service account unlock is not supported in this release.

  • User may not able to see the device location.

    WorkAround: Go to user policy Endpoint Policies > Common Settings > Mobile Settings > Restriction Settings, then under Report mobile device location select Force for Permit administrator to see device location.Then unenroll the user and enroll again.

  • Mac login MFA options show FIDO2 and Radius if they were configured in the authentication profile; however, these MFA challenges are currently not supported.

    Workaround: Always make sure authentication challenges configured in the authentication profile are available to your users and configured for each user.

  • The local account can get out of sync with the matching account in the directory source after the password change, resulting in a denied login.

    Workaround: Log in to a local admin account and set the local password of the impacted user to the same password as the directory source through System Preferences  Users or through the dscl command line.

  • When creating an authentication profile for Mac MFA, password must be the first factor (Challenge 1).

  • A user might get removed from the FileVault boot screen if they changed their password without entering their previous password in the Keychain Sync dialog on 10.14.3+ macOS devices.

    Workaround: To avoid this issue, users should log out after changing their password in the User Portal. When they log back in, click Yes at the Keychain Sync prompt and enter their previous password to sync their keychain and FileVault password.

  • Apple Watch unlock is not compatible with the MFA lock screen policy

    Workaround: Disable the MFA lock screen policy for Apple Watch users in the Admin Portal.

  • Idaptive Menu Item is not removed from the UI after unenrolling until the next login or restart.

    You might receive a certificate error during munkiimport after tenant migration.

    Workaround: Re-enroll the Mac

  • MFA Lockscreen is disabled in macOS 10.15 due to an Apple bug which we expect will be fixed in an upcoming patch release. For the 19.6 Mac Cloud Agent, the normal macOS lock screen with password will be shown.

  • The Apple Device Enrollment Program (DEP) needs to be configured explicitly to work with the 19.6 Mac Cloud Agent. Please contact support if you plan to use DEP.

iOS client

Derived credentials functionality for iOS devices is not available in 20.2. The existing devices already enrolled for derived credentials will continue to work, but no new devices will be able to setup derived credentials. We'll be adding this functionality back in an upcoming release.

Lifecycle management

If a duplicate LDAP configuration is added (duplicating the host/port, BaseDN, and unique identifier mapping from an already-existing LDAP configuration) then the configuration will appear to be added successfully. However, the duplication causes errors with the previously existing LDAP configuration, and attempting to delete the duplicate configuration deletes BOTH configurations, resulting in "orphaning" all of the users associated with the previous LDAP service.

Workaround: Do not create duplicate LDAP configurations.