Centrify Privileged Access Service will now support adding Cloud IaaS Providers starting with AWS in order to support the vaulting and management of both root/billing account credentials, as well as IAM user account credentials.
Vaulting and SSO login for AWS root account, its password, and multi-factor authentication (MFA) secret token.
Admin-assisted password rotation for AWS root account password.
Support for enabling AWS MFA using Centrify as the virtual MFA device. This facilitates establishing Amazon's best practice for protecting the AWS root account from compromised credentials while still maintaining strong governance by the vault.
Vaulting of IAM access key secrets for IAM users. Centrify will be expanding this set of capabilities for AWS and other IaaS Cloud Providers in the future over the next several releases.
Centrify Platform Adds Support for Centrify Gateway Connector Registration Codes
Centrify recently updated its Centrify Platform in release 20.5 to support the automated registration for new Centrify Gateway Connectors to the Centrify Platform using a registration code. This release adds the required admin interface to create, modify, and retrieve registration codes for Centrify Gateway Connectors. Admins can now delegate the registration of new Centrify Gateway Connectors that may be required within a new project to the project owner or the automation tooling used to create that project without granting additional rights to the project team. As an example, Centrify has published a sample Terraform script that will auto-create a VPC with dual availability zones and then deploy and register Centrify Gateway Connectors within each availability zone in the private subnet. You can find that example in the Terraform-Connector-Automation project on Github.com/Centrify.
Centrify Platform Support for Silent Request for External Radius Server
With this release, the Centrify Platform will support a silent request for an external RADIUS server; you can now opt to generate the initial RADIUS AccessRequest with a specified fixed answer and then forward it over to the RADIUS server. Once the response to the initial AccessRequest is received, MFA will continue as normal. Today, the Centrify Privileged Access Service uses your existing RADIUS server for user authentication by enabling communication between your RADIUS server and the Centrify Gateway Connector (acting as a RADIUS client). When the MFA mechanism is set to an external RADIUS server, the Centrify Platform sends the user credentials (username and passcode) to the Centrify Gateway Connector, which validates them against the configured RADIUS server, and subsequently returns the result of that validation. Prior to this feature, the user would have to manually answer the initial RADIUS AccessRequest, but now with the silent request support, the Centrify platform will automatically send adaptive push-notifications based on the provided fixed answer directly to the user's registered device. This allows you to streamline the use of any custom configurations of an external RADIUS Server by minimizing the need for user intervention.
Offline Passcode Support for Centrify Client for Windows via the Centrify Mobile App
Centrify Client for Windows supports offline access with MFA required for when a machine loses connectivity with the Centrify Platform using the updated Centrify Mobile App. Users who have been granted the offline rescue permission to login can now use the Centrify Mobile App to retrieve the offline rescue one-time-password (OTP) for any vaulted system on which they have the view and rescue permission. The Centrify Mobile App also allows users to retrieve resource account credentials (domain, database, and system) from the Centrify Privileged Access Service based on their permissions.
Changes in 20.6-HF3
The following change was made in 20.6-HF3:
Eliminated a few unnecessary database updates during authentication (CC-75879).
Fixed an issue that a background refresh may be triggered unnecessarily when a user is updated (CC-76467).
Changes in 20.6-HF1
The following change was made in 20.6-HF1:
Fixed an issue that Centrify Connector may unexpectedly crash on RDP/SSH services (CC-75879).
Changes
The following list records issues resolved in this release and behavior changes.
While a tenant is being moved between pods in 20.5 and earlier an http 401 was returned for any incoming API call made, however this was confusing to callers, as this is usually only returned for a permissions issue, and cagent callers would go into disabled mode assuming the back end was no longer available. From 20.6 an http 403 will be returned (CC-76117).
The -S switch on cenroll has been enhanced. Previously, when sending multiple values of a setting through multiple parameters in cenroll, only the last value was considered and older values were overwritten. Now the parse function has been enhanced to merge the values for any already existing keys in the map (CC-75613).
Password reconciliation now functions when User Cannot Change Policy is enabled (CC-76145).
Resolved an issue with some Desktop apps where they would not launch correctly for some users. If the failing app used RDS the same user could access using the native RDS Web page (CC-76133).
Hyperscale Privilege Access Service now configures SignalR Redis to support Web RDP/SSH when there are multiple Web nodes (CC-76156).
Resolved an issue with slow RPC to Connectors where there are multiple subnets configured in the Connector machines including some subnets that were unreachable by the cloud back end (CC-76087).
The discovery job now no longer throws an exception when the debug configuration is enabled when saving the report (CC-75949).
A configured local administrator account on any UNIX system no longer blocks deleting that system (CC-75215).
The systems tab is now correctly refreshed if permission is granted from an account set on Hypserscale Privilege Access Service and Self Hosted Privilege Access Service (CC-75545).
A new UI setting, “Display banner at portal login” has been provided to allow a customer-provided banner to be displayed to all users upon login (CC-75803).
Challenge pass through support has been added to the security API: - /security/StartChallenge now supports “on behalf of” challenges for oauth client and connector service users. In on behalf of mode, StartChallenge will switch context to the user associated with the challenge ID before proceeding with challenge initiation. - /security/OnDemandChallenge now supports “challenge mode” for the user. If no challenge is needed, Auth Success will be returned by OnDemandChallenge, otherwise and MFA challenge will be initiated for the user with appropriate mechanisms and an auth package returned. (CC-75259).
Global and policy settings are now provided for local account automatic maintenance and to enable local account manual unlock (CC-74336).
It is no longer necessary to specify a customer suffix when creating a Centrify Directory user (CC-36452).
Supported Platforms
Centrify Connector
Windows Server 2012r2, Server 2016, Server 2019
Self-hosted Centrify Privileged Access Service
Windows Server 2012r2, Server 2016, Server 2019
Hyper-scalable Centrify Privileged Access Service
Windows Server 2016, Server 2019
Centrify Clients for Linux
Client for Red Hat 6:
Red Hat Enterprise Linux 6.9, 6.10, 7.5, 7.6, 8.0, 8.1
CentOS 6.9, 6.10, 7.5, 7.6, 8.0
Fedora 30, 31
Oracle Linux 6.9, 6.10, 7.5, 7.6
Amazon Linux AMI 2017.09, 2018.03
Amazon Linux 2 2017.09, 2018.03
Client for CoreOS
Latest stable release 2345.3.0
Client for SUSE 11
SUSE 11
Client for SUSE 12
SUSE 12, 15
Client for Debian 8
Debian 8, 9
Ubuntu 16.04LTS, 18.04LTS, 18.10, 19.04
Centrify Client for Microsoft Windows
Windows Server 2012r2, Server 2016, Server 2019
Windows PAS Remote Access Kit
Windows 10, Server 2012r2, Server 2016, Server 2019
Centrify app for Android
Android 4.4 (API level 19) and later
Centrify app for iOS
iOS 11 and above
(Tested systems and devices for Privileged Access Service are listed in the documentation).
