• Deployment

Release Notes for This Release

39.0

2025-03-31

39.0 is a major release with new features.

After this release, we provide security and stability fixes for PrivX 39.x, 38.x, and 37.x. Older versions are not officially supported. We recommend you upgrade as soon as you can if you are running an unsupported version.

Supported upgrade paths to this release are:

  • Upgrade with downtime: 36.x, 37.x, 38.x
  • Zero-downtime upgrade: 38.x

The latest PrivX LTS version is v36, which can be obtained here.

Important Notes for This Release

Switch to discoverable passkeys

From PrivX v39 and later, any passkeys added to PrivX will be discoverable. When choosing to log in using a passkey, you may select from any credentials you've registered.

Note that any passkeys added in v38 and earlier are undiscoverable, and support for undiscoverable passkeys will be discontinued in a future release: If you have added passkeys in v38 or earlier, re-add those in v39 to ensure continued functioning.

For more information about setting up passkey login, see Passkey Login.

Changes to sshexec and exec router control commands (since v38)

From v38 and later, network-access manager now sends an extra {session parameters} argument to the control commands of sshexec routers and exec routers.

  • For sshexec router, network-access manager now executes the fixed commands:
    /opt/privx/privx-router/sshexec/add {network parameters} {router parameters} {session parameters} [{static config}]
/opt/privx/privx-router/sshexec/del {network parameters} {router parameters} {session parameters} [{static config}]
  • For exec routers, network-access manager now executes the fixed commands:
    /opt/privx/privx-router/exec/add {network parameters} {router parameters} {session parameters} [{static config}]
/opt/privx/privx-router/exec/del {network parameters} {router parameters} {session parameters} [{static config}]

The {session parameters} contains session parameters in JSON format, for example:

{
  "session_id": "f5d747f6-af79-412b-4471-b6f5043c90ce",
  "target_id": "07bee1e7-7061-4a90-4831-f501bcbc778e",
  "target_name": "ot-sshexec-target"
}

This change may break existing sshexec/exec routers that can't accommodate the extra argument. Such scripts/binaries will need to be changed to support the additional argument.

For more information about sshexec/exec routers, see PrivX Router Configuration.

Retaining SID extensions in RDP-certificate authentication (since v37)

In PrivX 36, RDP certificates issued by PrivX for authentication contain the SID extension by default. Some legacy use cases are interrupted in some customers environment because of missing or mismatching SID values. From PrivX 37 and later, PrivX supports a setting to control whether the SID extension shall be included in RDP certificates.

If you are upgrading from 36.0 or 36.1, and want to keep your existing default settings for RDP certificate, you will need to perform additional configurations. You can perform these configurations either before or after upgrade:

Option 1: Configure before upgrade

Configuring before upgrade allows RDP certificate authentication to work throughout the upgrade process.

  1. Gain root terminal access to any PrivX Server, add the following lines right after the AUTHORIZER.logging section in /opt/privx/etc/settings-default-config.toml:

    [AUTHORIZER.ca_settings]
rdp_x509_include_sid = true

  2. Apply the new settings with:

    sudo /opt/privx/bin/settings-tool -command migrate

    RDP-certificate authentication will work as normal throughout the upgrade process.

Option 2: Configure after upgrade

If you choose to configure after upgrade, RDP certificate authentication will not work until the following configurations are done.

  1. After upgrade, go to Administration→Settings→Authorizer, then under CA Options, enable the setting Add Security ID extension to RDP X.509 certificates.

    Save your changes. RDP-certificate authentication should function normally again.

Deprecation Warnings

agent-proxy Deprecated

The agent-proxy functionality has been removed in PrivX versions 39 and later.

The agent-proxy functionality allowed SSH clients using privx-agent to connect to Extender targets through ssh-proxy. In recent PrivX versions, you can instead use native SSH clients via SSH Bastion, as described here.

Pure whitespace names disallowed

From version 37 and onward PrivX no longer be able to create items whose names consist purely of spaces. Also, you will be unable to update such items until their names are changed to contain some visible character(s).

Amazon Linux 2 support Ending

PrivX aims to end installation support for Amazon Linux by June, 2025. See Migrate from EOL Operating Systems to migrate to a supported OS.

SHA-1-Certificate End of Support Imminent
Support for certificates signed with SHA-1 shall be dropped in future PrivX releases.

By default PrivX will not trust certificates with SHA-1 signatures unless they are self-signed. Re-enabling trust for such certificates requires setting the GODEBUG=x509sha1=1 environment variable for PrivX microservices and tools.

Practical attacks against SHA-1 have been demonstrated in 2017 and publicly trusted Certificate Authorities have not issued SHA-1 certificates since 2015.

New Features

  • [PX-7130] Allow administrators to select the SMTP authentication method.
    • New setting SMTP Authentication Mode under Administration→Workflows→Email Notification Settings.
    • New supported authentication method XOAUTH2.
  • [PX-7236] Administrators can now provide an additional issuer URL for OIDC directory settings, such as Oracle Cloud.
    • This allows OIDC-login support for non-standard configuration where the issuer URL reported by the OIDC identity provider is different from the discovery endpoint URL.
  • [PX-7295] New setting Trust on changed host keys for SSH services.

Improvements

  • [PX-7388] Support for discoverable passkeys.

Bug Fixes

  • [PX-7594] Directory scan fails to update host running status if the host is configured with command restrictions.

Known Issues

  • [PX-1517] Permission denied for AuthorizedPrincipalsCommand on AWS RedHat AMI

    • Workaround: To correct SELinux context, copy the principals_command.sh to correct location:

      # scp -i key.pem principals_command.sh user@target:/tmp/
# ssh -i key.pem user@target "sudo cp /tmp/principals_command.sh /etc/ssh/"

  • [PX-1711] RDP fails to connect to target in maintenance mode, need support for /admin flag

  • [PX-1835] Extender/Carrier/WebProxy configs are not migrated on upgrade

  • [PX-1875] Web proxy login does not work, if login page does requests to multiple domains

  • [PX-2947] No sound when viewing recorded rdp-mitm connection.

  • [PX-3086] PrivX role mapping to AD OU not working as expected.

  • [PX-3529] Default access group CA key is always copied on the host when running the deployment script via Extender

  • [PX-3655] remoteApp cannot be restored after it's minimized

  • [PX-3887] RDP connection to Remote Desktop Server(RDS) Farm is not supported.

  • [PX-4218] RDP native clients do not work in Kubernetes environment when running under non-root account

  • [PX-4352] UI shows deleted local user after delete

  • [PX-4616] Upgrade may stop Carriers and Web Proxies from reconnecting.

    • Workaround: Restart affected Carrier and Web-Proxy services.

  • [PX-4662] Pasting larger text amount in Carrier/Proxy host fails (limited to 16kB for now)

  • [PX-4689] PrivX Linux Agent leaving folders in /tmp

  • [PX-4778] RDP-PROXY: file under scanning can not be overwritten

  • [PX-4809] Empty file(s) created when ICAP detects malicious uploads with SCP via SSH Bastion.

  • [PX-5558] PrivX does not support password change required option for user in auth flow via passkey.

  • [PX-5587] Live playback of WEB will be stuck in live after disconnecting by closing the carrier browser

  • [PX-5589] User cannot login with PrivX Agent if password includes a SPACE at start/end

  • [PX-6209] Attribute mapping for OIDC does not work, if idtoken source attribute name is not all lowercase

  • [PX-6464] Secret-manager crash if database doesn't have valid TLS certificate

  • [PX-6490] PrivX RDP session screen corrupts in Windows 2008 via Chrome and Edge browsers

  • [PX-6636] Web-target vCenter key strokes is not working properly in Bios/Grub menu

  • [PX-7393] Role mapping rules: an "Any Rule Matches" group with nested groups causes an error

  • [PX-7524] Host search sort does not work

Important API Changes

Workflow-engine endpoints now support the optional smtp_authentication_mode, which defines how PrivX authenticates to the SMTP server used for sending workflow-related email notifications.

smtp_authentication_mode is supported by the following endpoints:

  • POST /workflow-engine/api/v1/testsmtp
  • POST /workflow-engine/api/v1/workflows
  • PUT /workflow-engine/api/v1/settings
  • PUT /workflow-engine/api/v1/workflows

The possible values for smtp_authentication_mode are:

  • "NO-AUTH"
  • "PLAIN"
  • "LOGIN"
  • "XOAUTH2"
  • "CRAM-MD5"
  • "SCRAM-SHA-1"
  • "SCRAM-SHA-1-PLUS"
  • "SCRAM-SHA-256"
  • "SCRAM-SHA-256-PLUS"

When smtp_authentication_mode is undefined, it defaults to "PLAIN".

Was this page helpful?