PrivX Product Update

This release is an intermediate release to deliver certain features before starting the development of PrivX 40.

 

Modern authentication for workflow emails

SMTP settings for PrivX Workflow emails now support more modern authentication methods, including XOAUTH2. One driver for this change is Microsoft Exchange Online will deprecate basic authentication by September 2025. 

 

Discoverable passkeys

Passkeys saved in PrivX 39 are now discoverable. This will allow more improvement on usability and security in future releases. Previously saved passkeys will continue to work, but we recommend that users re-enroll new passkeys at their convenience.

 

Trust on changed host key

Non-admin end users can accept changed SSH host keys. PrivX admin can allow users to accept new host keys when they are updated or renewed.

 

Additional Host Directory settings

Admin can 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.

 

For more details about the PrivX 39 release, read the full release notes.

This release extends Quantum Safe support, enhances cloud support, improves management of PrivX Extenders. In addition, some features improving performance usability are delivered. 

Support for ML-KEM based PQC algorithms

Continuing on path to be quantum safe PrivX now supports ML-KEM in addition to already existing KEX (Key Exchange) algorithms.

ML-KEM (Module Lattice-based Key Encapsulation Mechanism) algorithm is part of the new standards released by the National Institute of Standards and Technology (NIST) to protect electronic information from quantum threats.

Key benefits of using ML-KEM:

• Quantum Resistance: Secure against quantum computer attacks.
• Standardization: NIST-approved for reliability and security.
• Performance: Efficient integration with existing systems.
• Versatility: Suitable for various applications like key exchange, encryption, and digital signatures.
• Global Adoption: Widely supported by major cryptographic libraries and software.
• Robust choice for future-proof data security.

List of all supported KEX algorithms can be found from PrivX online documentation.

PrivX to control NQX (dynamic tunnels)

Related to quantum safe, especially to site-to-site quantum safe connectivity it is possible to configure parameters in Network target access configuration for controlling NQX. Using RBAC, PrivX users can create Quantum safe tunnels on demand. (E.g., allowing access to specific site or network segment)  

It is possible with static Network target configuration:

When using the exec or sshexec type PrivX routers, it is possible to specify a router integration provider in the network target configurations. This is used to define the target static configuration passed to the router. If the provider is generic, any valid JSON object will be sent as the last (optional) parameter to the router.

If the provider is NQX, the static configuration can be configured in GUI. NQX network target integration supports l3rules, tunnel, and combo types. 

 

SSH NQX™ is a quantum-safe encryption solution designed to provide high-bandwidth, secure data transmission, i.e. between sites or datacenters. Here are some key features and benefits:

• Quantum-Safe Encryption: Uses advanced post-quantum cryptographic algorithms to protect data against future quantum computer threats.
• High Performance: Capable of transmitting data at speeds up to 100Gbps, making it significantly faster than many existing enterprise tunneling solutions.
• Versatility: Supports both Ethernet (L2) and IP (L3) protocols, allowing secure data transmission over various network environments.
• Future-Proof: Designed with crypto agility, enabling the use of the latest PQC algorithms as they emerge and running classical algorithms in parallel.
• Certified Security: Certified by the Finnish National Cyber Security Authority (NCSA) for the transport of classified data, ensuring compliance with stringent security requirements.  

Oracle Cloud as host directory

PrivX can be configured to fetch cloud instances or hosts through cloud APIs. For cloud hosts, PrivX will also show instance status and cloud region in the administrator user interface.

PrivX supports the following cloud environments as host directories:

• Amazon AWS

• Google Cloud Platform

• Microsoft Azure

• OpenStack

• Oracle Cloud (New)

• VMWare vSphere

• PrivX can also use Universal SSH Key Manager as a Host Directory.

 

After a host directory is configured, only hosts that are in usable state are imported to PrivX. This means cloud hosts in states like 'Stopped', 'Terminated' and so on are not imported to PrivX. Different clouds have different terminologies for the host states.

 

Functionality of upgrading PrivX Extenders from GUI was introduced already in PrivX 37, supporting upgrades from version 37 onwards.

New Software versions can be uploaded centrally to PrivX from the GUI and then distribute and upgrade the Extenders.

 

Possibility to logout user from PrivX UI after being inactive for some preconfigured period of time.

If a PrivX user is inactive in their GUI session, they can be automatically logged out after a specified duration.

You can configure this in Settings→Authentication→User Session Inactivity→Session Inactivity Limit (Seconds). This will automatically log out GUI users if they are not actively interacting with any PrivX-GUI tab. Users will be logged out regardless of whether there is token activity, which can happen while tabs are open in the browser.

Email notifications

Sending email notifications to all approvers when request is approved, denied, or revoked. This helps keeping everybody aware of role request statuses.

New workflow setting

Admin can make justification as mandatory field. Requesters must provide justification for role requests.

The Web Content Accessibility Guidelines (WCAG) have three levels of conformance to help ensure web content is accessible to everyone, including people with disabilities. These levels are:

WCAG Level A: This is the most basic level of accessibility. It includes essential requirements that must be met to ensure web content is accessible. Failing to meet Level A criteria can make it difficult or impossible for some users to access the content.

WCAG Level AA: This level builds upon Level A and includes additional criteria to address a broader range of accessibility issues. Meeting Level AA ensures that web content is accessible to a wider audience, including people with different disabilities. Level AA is often the target level for legal and regulatory compliance.

WCAG Level AAA: This is the highest and most comprehensive level of accessibility. It includes all criteria from Levels A and AA, plus additional requirements to make web content even more accessible. Achieving Level AAA conformance is ideal but can be challenging for all types of content.

Based on VPAT (Voluntary Product Accessibility Template) assessment PrivX GUI supports accessibility at level AA outlined by WCAG 2.1.

For more details about the PrivX 38 release read the full release notes.

This maintenance release is aimed at enhancing product quality and architecture. Alongside refining functionality and resolving bugs, we've also added features to facilitate easier management of PrivX components through the GUI and introduced support for the new HSM. 

 

Upgrading PrivX Extenders centrally via PrivX GUI

The PrivX Extender is an optional component of the PrivX that facilitates secure connections to target hosts that are not directly accessible by PrivX. It acts as a reverse proxy, relaying connections to hosts located behind firewalls, NATs, or in Virtual Private Clouds without public IP addresses. This allows PrivX to manage and secure access to these otherwise unreachable systems.

Besides the option to manually upgrade Extenders locally, future updates can be performed centrally through the PrivX GUI.

This functionality is available for upgrades from version 37 to 38 and onwards.

Detailed instructions in the online documentation.

 

Rotating CA Certificates via the PrivX GUI

PrivX Extenders, Carriers, and Web Proxies are issued certificates, which need to be renewed periodically. Each PrivX deployment issues these using the following Certificate Authorities (CA):

• PrivX Extender/Carrier

• PrivX Web-Proxy (ICAP)

By default, these CAs are valid for five years. Note that Carriers and Extenders share the same CA.

In addition to the previous CAs, the Database Proxy also offers a CA certificate which can be optionally used by database clients to verify their connections to PrivX.

CA's can now be renewed through the PrivX GUI (under Administration→Deployment).

Detailed instructions in the online documentation.

 

Support for Thales’ CipherTrust Manager as HSM Provider

Instead of storing PrivX cryptographic keys on PrivX servers, you can store them on your Hardware Security Module (HSM).

Hardware Security Modules (HSMs) enhance security by securely managing cryptographic keys, ensuring compliance with regulations. They offer high performance for cryptographic operations, robust key management, and scalability. HSMs isolate cryptographic tasks, reducing key exposure risk and enhancing data integrity and trust.

 

Configurable "Scrollback Length" for SSH web client

For browser-based SSH connections it is possible to configure scrollback buffer size.

 

 

For more details about the PrivX 37 release, read the full release notes.

This release improves functionality for Windows password rotation and certificate-based authentication. In addition, some features improving performance usability are also delivered. 

 

Windows RDP certificate authentication support in Full-Enforcement domains

PrivX uses short-lived certificates to authenticate users and hosts, eliminating the need for passwords, keys, or agents. In Microsoft environments, virtual smart cards are used to provide passwordless access to Windows servers.

Microsoft has introduced some changes in taking Security Identifiers (SID) into use on domain controllers to improve security and performance. When the change is implemented, domain controllers in Full-Enhancement mode require an authentication certificate to support SID extension. 

PrivX 36 supports auto-scanning or manual config of SID for authentication certificates to Windows RDP hosts. Certificates issued by PrivX include Object Identifier extension which contains the SID value for RDP login. 

Read more on Microsoft: KB5014754: Certificate-based authentication changes on Windows domain controllers

 

Windows local account password rotation supports hosts behind PrivX Extenders

PrivX can rotate passwords for Windows hosts using WinRM, a remote management protocol.

PrivX connects to the Windows host via WinRM, authenticates with the current password, and runs a PowerShell script that changes the password to a new random value. The new password is stored in the PrivX vault and used for future access. PrivX can also rotate the local administrator password, which is needed for WinRM authentication.

PrivX WinRM-based password rotation feature is a convenient and secure way to manage passwords for Windows hosts. It leverages the WinRM protocol to remotely change passwords and stores them in the PrivX vault for secure and auditable access. It enhances security, compliance, and user experience for privileged access management.

PrivX 36 supports now WinRM-based password rotation through Extender. 

PrivX Extender enables PrivX to connect to target hosts that are located behind firewalls, NATs, or other network barriers. PrivX Extender acts as a reverse proxy that establishes outbound connections to the PrivX Controller and relays traffic between the PrivX Controller and the target hosts.

 

Allow user to copy text in disconnected ssh-proxy sessions

If for some reason an SSH connection gets disconnected in browser-based connections it is possible to keep the terminal window open and copy text from “disconnected” terminal window.

 

Domain password login supports Tectia server

PrivX Tectia SSH server uses sAMAccountName as an authentication method. It is a simple and convenient way to log in to a domain-joined computer or a web application that supports Windows authentication. When using a domain account to log into a Tectia Server, it expects the login name is in “domain\sAMAccountName” format, while PrivX 35 only supports domain account login with account name in UPM format. 

PrivX 36 supports "domain\sAMAccountName” format in the host principal for SSH connection to a Tectia Server when the principal is a domain account. PrivX can continue to manage and rotate the domain account password to enhance security.

 

 

For more details about the PrivX 36 release, read the full release notes.

This release includes functionality for Domain password rotation and PrivX Carrier to support Podman deployment. In addition, some features improving performance usability are also delivered. 

 

Domain Password Rotation

PrivX domain Password Rotation is a new major feature added to PrivX in version 35.0. It allows PrivX to manage the passwords of AD and Entra ID accounts, rotate them periodically, after use or on demand, and provide secure access to the secrets for authorized users. It supports various use cases, such as account discovery and onboarding, target server login with fallback to the previous password version, host secret checkout, and managing static passwords. In this blog post, we will explain the benefits of this feature, how it works, and what are the use cases and scenarios that it covers.

 

Why Do You Need the Domain Password Rotation Feature?

Managing the passwords of AD and Entra ID accounts can be a challenging and time-consuming task, especially in large and complex environments. You need to ensure that the passwords are compliant with the security policies, that they are changed frequently and securely, and that they are not exposed to unauthorized users or attackers. You also need to provide access to the passwords for the users who need them, without compromising the security or accountability of the access. Moreover, you need to monitor and audit the password management and access activities and generate reports and alerts for any anomalies or issues.

PrivX AD Password Rotation feature can help you automate and simplify the password management and access process and improve your security and compliance posture. With PrivX, you can:

• Discover and onboard accounts from AD and Entra ID directories and assign them to password rotation policies and access roles.

• Rotate the passwords of managed accounts in AD and Entra using randomly generated passwords according to the password policy. PrivX can also verify the passwords after rotation and

• Have support for rotation in multiple AD/Entra directories in parallel.

• Allow users to explicitly check out the password versions of managed accounts, with access control based on the users' roles and host accounts' required roles. Checkout exclusivity and maximum allowed duration can be specified in the password policy.

• Connect to the target servers using RDP proxy, SSH proxy, and SSH bastion, and retry login with the previous password version if the latest one fails. RDP bastion and DB proxy support automatic login only using the latest password.

• Generate audit events for configuration changes, account discovery/onboarding, password rotation, and secret checkouts. Password rotation history can be inspected per managed account.

 

How Does the PrivX AD Password Rotation Feature Work?

The PrivX AD Password Rotation feature consists of the following components and steps:

• Target Domains: PrivX can represent an AD domain in its data model and REST API, and discover accounts from AD and Entra, including failover support. Accounts can be manually or automatically onboarded to PrivX as managed accounts.

• Password Policies: PrivX allows you to create and configure password policies that define the password complexity, length, expiration, verification, rotation frequency, and checkout options for managed accounts. You can assign password policies to managed accounts, and PrivX will enforce them accordingly.

• Password Rotation: PrivX can rotate the passwords of managed accounts in AD and Entra using randomly generated passwords according to the password policy. It can also verify the passwords after rotation and support parallel rotation in multiple AD/Entra directories. PrivX stores the password versions in its encrypted vault and keeps track of the rotation history and status.

• Host Secret Checkout: PrivX can allow users to explicitly check out the stored password versions of managed accounts, with access control based on the users' roles and host accounts' required roles. Checkout exclusivity and maximum allowed duration can be specified in the password policy. PrivX will release the secret checkout and trigger password rotation when the checkout expires or is manually terminated.

• Target Server Login with Fallback to Previous Password Version: PrivX can connect to the target servers using RDP proxy, SSH proxy, and SSH bastion, and retry login with the previous password version if the latest one fails. RDP bastion and DB proxy support automatic login only using the latest password. PrivX will record the login sessions and audit events for accountability and compliance.

Example of target domain configuration and password rotation policy

 

Use cases and scenarios

The PrivX AD Password Rotation feature can support various use cases and scenarios, such as:

• Account Discovery with Manual Onboarding: An administrator configures the target domain, account scanning, and password rotation and creates password policy and DIRECTORY accounts. PrivX scans the AD/Entra directory and stores discovered accounts in the database. Administrator manually converts discovered accounts into managed accounts, sets password policy, triggers initial rotation and optionally enables explicit checkout. User logs into PrivX, requests access to a target or secret, and PrivX connects to the target using the available password versions, or the user uses the password manually. Secret checkout is released, and password rotation is triggered.

• Automatic Account Onboarding: Administrator creates password policy for automatic account onboarding, sets the auto onboarding limit, and creates target domain with periodic scan and auto onboarding enabled. PrivX scans the AD/Entra directory and automatically converts discovered accounts to managed accounts using the auto onboarding policy and triggers initial password rotation. User logs in to PrivX, requests access to target or secret, and PrivX connects to the target using the available password versions, or user uses the password manually. Secret checkout is released, and password rotation is triggered.

• Managing Static Passwords: Administrator creates target domain, password policy and manually creates managed accounts with static passwords. Administrator configures DIRECTORY or EXPLICIT accounts to host objects. Password for an account is changed in AD, administrator provides the new static password for the respective managed account. User logs in to PrivX, requests access to target or secret, and PrivX connects to the target using the available password versions, or user uses the password manually. Secret checkout is released and password rotation is triggered.

 

Conclusion

PrivX AD Password Rotation feature is a powerful and flexible solution that can help you manage the passwords of AD and Entra accounts, and provide secure access to the secrets for authorized users. It can improve your security and compliance posture, reduce your administrative overhead, and enhance your user experience. To learn more about PrivX, you can read the documentation, watch the demo video, or request a demo or free trial of PrivX.

 

PrivX Carrier to Support Podman Deployment

In addition to Docker CE, PrivX Carrier can be deployed with podman. The docker package is not shipped or supported by Red Hat for Red Hat Enterprise Linux (RHEL) 8 and (RHEL) 9. The docker container engine is replaced by a suite of tools in the Container Tools module.

The podman container engine replaced docker as the preferred, maintained, and supported container runtime of choice for Red Hat Enterprise Linux 8 and 9 systems. The podman provides a docker compatible command line experience enabling users to find, run, build, and share containers. The podman uses buildah and skopeo as libraries for the build and push.

 

Dropping Support for PostgreSQL Versions 9 and 10

We are dropping support for PostgreSQL versions 9 and 10, which are not officially supported anymore.

 

For more details about the PrivX 35 release, read the full release notes.

This release is a maintenance release, focusing on improving the product quality and architecture. In addition to improving functionality and fixing bugs, we managed to include a feature for UKM as a host directory for PrivX. Improvements and fixes are listed in the release notes.

 

UKM as a host directory

We believe that the gaming setup for an e-athlete is like the instrument for a musician. You can start with any setup, but when competing with the best, every detail count to get the edge and win those milliseconds.

 

For more details about the PrivX 34 release, read the full release notes.

In PrivX 33, we are delivering many new features as well as improvements to existing functionality.

 

This feature provides an ability to upgrade a PrivX high availability environment without service interruptions. This allows users to log in and connect to targets/hosts during the upgrade process. PrivX is running in maintenance mode restricting API functionality and some tasks until the upgrade finished. This will prevent problems during the database schema migrations. Zero downtime upgrade can be done from PrivX version 32 onwards. Upgrade can be done to later minor releases or the next major version. (for example, from PrivX 33.0 to 33.1 or 34.0)

If you want to upgrade over multiple major versions at once, e.g., from 33 to 35 it can be done with the old upgrade process (with downtime).

 

With the improvements in home UI, it is easier to present relevant information and that way help users to be more productive and aware of what is going on. 

The feed of recent activities can be filtered based on activity type:

• Alerts

• Connections

• Role requests

• Role approvals

Home UI provides easier access to favorites and documentation search. Elements visible on the right side of the home UI can be configured by the user (Service Status, Favorites, documentation and My Roles). The current version is an enabler for future development.

 

Sometimes solving problems requires more detailed logs to be delivered to support engineers. Previously changing debug level required restarting PrivX, so enabling more detailed logging required planning and proper timing to avoid service interruptions. Now the debug level can be changed per microservice from UI without restart.

 

In some environments, it is important to hide some roles to be visible to everyone when requesting roles through a built-in workflow engine. Especially in Operational technology environments where the ecosystem consists in addition to internal users also multiple external organizations (vendors, System Integrators, maintenance engineers, etc.) In version 33 it is possible to limit the visibility of the role to be requested. Users need to have a specific requester role to see certain roles in the role request form's drop-down menu. Those roles are not visible for users without the requester role. As an example in pictures user can see the db-access-role in the dropdown menu only if he has System Integrator A role.

 

PrivX integrates seamlessly with multiple Identity Management Systems using them as a user directory. With Microsoft Entra ID (formerly known as Azure AD) the integration is done through Microsoft Graph API. You can map directory user attributes (source) to PrivX user attributes (target). 

Supported source fields since PrivX 33 are: principal, mail, name, cn, givenName, sn, usageLocation, mailNickname, city, companyName, onPremisesSAMAccountName, onPremisesUserPrincipalName, onPremisesDistinguishedName, country, department, officeLocation, jobTitle, preferredLanguage, employeeId, mailNickname, employeeType, state.

In addition to these supported source fields, it is possible to define custom attributes. 

 

PrivX documentation has moved to a new documentation platform. The move is transparent for users. You may access the latest version of PrivX docs as usual at https://privx.docs.ssh.com. If you need to access older documentation versions, specify the version in the URL. For example, PrivX 29 at https://privx.docs.ssh.com/v29.

 

 

For more details about the PrivX 33 release, read the full release notes.

 

Data regarding Roles, Users, Hosts, and Network Targets can be exported in CSV or JSON format.

 

When configuring session recording for the hosts, it is possible to disable clipboard and file transfer recording. You may optionally omit clipboards and/or file transfers from recordings. This can be useful for example if such content contains sensitive information like user credentials. 

 

Connections to the target host can be initiated straight from the host configuration page. Useful e.g., for testing connections during host configuration.

 

When transferring large files or large amounts of files user can continue working on the terminal window or remote desktop while files are being uploaded. Visible notification is shown when the file transfer is finished.

 

Already in PrivX release 8, we introduced the feature that enabled PrivX to manage access to Web resources based on roles (RBAC) through an isolated browser. All sessions can be recorded and played back afterward. Audit events are stored in syslogs for further analysis. The most common use cases would be accessing critical web resources with shared accounts. These could be Admin consoles of network devices, admin portals to the company’s SaaS services, or internal Web tools (Salesforce, Twitter, LinkedIn, etc.).

 

PrivX extender supports UDP protocol in addition to TCP/IP. This is needed for example for making Network Target connections through the Extender with applications using proprietary protocols over UDP or mixture of TCP/IP and UDP.

 

PrivX can be configured to fetch cloud instances or hosts through cloud APIs. In addition to existing host directories VMWare vSphere is also supported:
•    AWS EC2 as a Host Directory
•    Google Cloud Platform as a Host Directory
•    Microsoft Azure
•    OpenStack
•    New: VMWare vSphere

 

 

For more details about the PrivX 32 release, read the full release notes.

This release is a maintenance release, focusing on improving the product quality and architecture. In addition to improving functionality and fixing bugs, we managed to include features for Certification Authority key rotation and adding tags to connection history as search criteria. Improvements and fixes are listed in the release notes.

 

PrivX Authorizer CA key rotation

Certain authentication methods such as certificate-based authentication require target-systems to be configured to trust PrivX as a Certification Authority (CA). For example, with Linux hosts, this may involve configuring Tectia or OpenSSH to trust the PrivX Certificate Authority. 
PrivX Authorizer creates the ephemeral certificates needed to access SSH and RDP target hosts via certificate authentication. Each access group is associated with a distinct authorizer CA key and a certificate used during authentication to target hosts. The CA key and certificate must be renewed before the certificate expires, or they need to be rotated regularly per company policies.

The rotation process involves the following steps:

• Create a new CA key in Administration→Access Groups→CA Key Details by choosing Renew CA Key

• Update the CA public key or certificate on all target hosts belonging to that access group (more on this below)

• Select the new CA key as the Primary CA Key in the Access Groups view

• Remove the old CA key once it is no longer used by any hosts

Target hosts using stored credentials for authentication are unaffected by CA key rotation.

 

Using tags in connection history

Keeping track of specific connections can be done by adding tags to connection information. Connections can be easily searched by using tags as search criteria.

 

For more details about the PrivX 31 release, read the full release notes.

This release includes functionality for Role-Based Access Control for Databases and improvements for using PrivX as an SSO solution (OIDC provider). In addition, features improving usability are also delivered.

 

Database access control

A long-waited-for feature for controlling access to Databases using native clients is finally available. Making Database connections using native DB-clients can now be controlled based on a user’s role. Access control works for interactive and scripted m2m/a2a connections.

Connecting to the target database

PrivX DB access supports PostgreSQL and MySQL wire protocols. For these connections, PrivX manages target database credentials. Access control for other DB-protocols, like Oracle database, can be done via Passthrough modes (TLS or Passthrough). In this case, access to the target database is granted based on the PrivX user's roles, but PrivX does not manage target database credentials.

Connection flow:

• User opens SSH tunnel to PrivX SSH bastion and connects DB client to target database through SSH tunnel via the DP-Proxy (SSH tunnel provides secure communications for unencrypted database protocols)

• PrivX SSH bastion forwards DB connections to DB-Proxy

• DB-Proxy grants/rejects connections based on the user's role

Monitoring and terminating connections

DB connection metadata is stored and displayed in PrivX UI, including Audit Evens. Connections can be terminated by admin if/when needed. Recorded protocol streams can be downloaded from PrivX UI in “hex” and “jsonl” format.

Summary of supported protocols

 

 

PrivX as OIDC Provider- Route https sessions through Carrier

PrivX can be used as a Single-Sign-On (SSO) solution for web applications, where it can be used as an OIDC Provider. In other words, it can perform user authentication and issue tokens/claims for accessing applications supporting OIDC-relying party functionality. Users can access web applications by login into PrivX. Application-specific login credentials are not needed. By default, the connections are not going through PrivX (no session recording) only the authentication is done with PrivX. From PrivX 30 onwards it is possible to route connections through the Carrier component. This enables the possibility to record the sessions.

As a summary for Web access:

• Directly to Web applications using their own browser without PrivX. Users log in as themselves and will take care of their personal credentials. Applicable for personal and work-related Web applications

• Using PrivX for SSO. Users log in as themselves. PrivX provides SSO authentication (OIDC). Web applications are configured to trust PrivX as Identity Provider. Actual https connections are not going through PrivX.

• PrivX provides SSO authentication (OIDC). Web applications are configured to trust PrivX as Identity Provider. Web applications are running in an isolated browser in PrivX Carrier. Actual https connection is going through PrivX. Sessions can be recorded.

• Existing OIDC solution can be used in conjunction and can provide SSO to PrivX (identity provider chain).

 

 

Chromium as an alternative Carrier browser

In PrivX 30, Chromium can be used as an alternative to Carrier Browser, supporting password injection through Chromium’s password manager.

 

For more details about the PrivX 30 release, read the full release notes.

This release includes a feature for enabling routing web connections through PrivX Extenders. In addition, features improving usability are also delivered.

 

Route web connections through Extenders

The basic use case for accessing web servers and routing traffic (HTTP/HTTPS/WS/WSS) via PrivX requires three components:

• PrivX core server
• PrivX Carrier
• PrivX Web Proxy

Previously the Carrier and Web Proxy components needed to be in same network where the Web Servers and applications were. In some environments it would have leaded to a situation where multiple Carrier and Web Proxy components needed to be deployed, thus raising infrastructure and maintenance costs.

​​Now Extender can be used to route web traffic to different networks. This allows using a single Carrier+Web Proxy setup to reach multiple VPN networks, reducing infrastructure costs and simplifying maintenance.

 

Easier configuration of disclaimers, headings, and watermarks

Configuring disclaimers, headings, and watermarks was done in JSON format. Now there is a better UI for doing it using text fields, checkboxes, etc.

 

PrivX login form is collapsible

When SSO functionality is taken into use, users do not need to enter their username and password to log into PrivX. Clicking the SSO button is enough. The login form can be now hidden by collapsing it. This helps users to focus on the SSO button instead of putting credentials to the login form. 
(Configuration through /opt/privx/etc/shared-config.toml)

 

“Secret” tab can be disabled

In some cases, there is no need to give users the possibility to manage user secrets. Access to that functionality can be disabled from PrivX settings.
(Configuration through /opt/privx/etc/shared-config.toml)

 

Admin tool

The admin tool is a command-line tool that can be accessed on the PrivX server. To use the tool, you must log in as root. Admin tool helps to recover from critical situations easier than before:

• Resetting password of local admin user (e.g., superuser)
• Resetting PrivX role context limitations 
  • If you lose admin access to PrivX due to misconfigured context limitations on critical roles

 

New keyboard layouts for PrivX web client connections

When making RDP, VNC or Https connections using browser it is possible to change the keyboard layout through connection settings. In addition to existing layouts Portuguese, Dutch and Romanian are supported now.

 

For more details about the PrivX 29 release, read the full release notes.

This release is a maintenance release, focusing on improving product quality and architecture. In addition to improving old functionality and fixing bugs, we managed to include a feature for improving audit-event-search performance using a trigram index. Details of the improvements and fixes are listed in the release notes.

 

Audit-Event Indexing for Faster Searches

This feature improves search performance, especially in large environments where the number of daily connections is hundreds of thousands or more.

 

Supported Releases and Upgrade Path

After this release, we will produce security and stability fixes for PrivX 28.x, 27.x, and 26.x. Older versions are not officially supported. We recommend you upgrade as soon as you can if you are running an unsupported version.

Upgrading to version 28 is supported by three previous major versions (27.x, 26.x, 25.x). For more information about upgrading from older versions see the full release notes.

 

For more details about the PrivX 28 release, read the full release notes.

This release delivers a bunch of new features and enhances existing ones: Passwordless login to PrivX UI using Passkey, Custom headings/watermarks to distinguish sessions, live monitoring for RDP/Web/VNC connections, viewing active users in PrivX UI, additional settings for auditing (performance optimization) and SSO support for PrivX as an IDP (OIDC provider).

 

Passkeys login (passkey authentication)

Passkeys login (using WebAuthn authentication) allows users to log into PrivX using a passkey (such as a fingerprint, Face ID, PIN, or YubiKey).

Passkeys are a safer and easier replacement for passwords. A passkey can replace a password and a second factor in a single step. The user experience can be as simple as auto-filling a password form. Passkeys provide robust protection against phishing attacks, unlike SMS or app-based one-time passwords. Since passkeys are standardized, a single implementation enables a passwordless experience across different browsers and operating systems.

WebAuthn authentication is supported on browsers such as Chrome, Safari, and Edge. Firefox is only supported on Windows 10. Note that the available authentication methods depend on the user's hardware (such as having the appropriate biometric readers) and operating system.

The feature can be enabled from PrivX settings.

 

Color heading and watermark in connections

When making connections to multiple targets and simultaneously working in different types of environments, e.g. development, testing, and production, it might be possible to lose traction in which environment you're working. Unintentionally you might make changes to the production environment instead of the test environment.

 

 

 

 

 

Enhanced real-time connection monitoring

For SSH connections, real-time monitoring was introduced in the previous release (PrivX 26). Now the real-time monitoring covers also RDP, VNC, and Web connections.

 

Show active users

PrivX admin can see users who are currently logged into PrivX. This is handy, for example, in situations when doing an upgrade or restarting PrivX after configuration changes.

Admin view can list user-specific events and connections (ongoing/history) and can terminate the user session (kick out the user from PrivX).

 

Settings for performance optimizations

The new exclusion list setting allows filtering audit events that are written to a database; normally, audit events are transferred to external systems like SIEMs/log collectors anyway. This way it is possible to optimize the database usage by excluding irrelevant ones. That's beneficial especially when running many M2M connections.

Data collected by PrivX is stored in multiple places. In order to save storage space, it is possible to configure retention policies for:

• Audit events (database)
• Connections Metadata (database)
• Trails (file system)

For trails, it is now possible to separate settings for Trail expiration and Trail transferred files expiration.

 

Single sign-on support for OIDC (provider)

When PrivX is used as OIDC Provider - in other words, using PrivX as an identity provider to perform user authentication and issue tokens/claims for accessing applications supporting OIDC-relying party functionality. Users can access web applications by logging into PrivX. Application-specific login credentials are not needed. Connections are not going through PrivX (no session recording).

Now PrivX users can authenticate to multiple websites, once they are logged into PrivX.

 

For more details about the PrivX 27 release, read the full release notes.

In this release, we are adding new features and improving existing ones. To highlight a few of them: More secure SSH connections with Post-Quantum Computing algorithms, automatic detection of anomalous connections (UEBA), live monitoring of SSH connections, and the possibility to use PrivX as an OIDC Provider.

 

Post-Quantum Computing Algorithms

Quantum computers already exist and their power is increasing. Soon, they will reach the point where classical cryptography is in danger.

With more sophisticated quantum computing technology, all data encrypted with classic encryption is vulnerable. Now is the time to start using Post-Quantum Computing algorithms. PrivX now supports new SSH KEX algorithms:

• ​​​​​​​ecdh-nistp521-kyber1024-sha512@ssh.com
• curve25519-frodokem1344-sha512@ssh.com
• sntrup761x25519-sha512@openssh.com

New algorithms are used, for example, in connections from PrivX to OpenSSH and Tectia Servers.

 

User and Entity Behavioral Analytics (UEBA)

Using machine learning it is possible to automatically detect suspicious behavior and take necessary actions. In the case of PrivX, it is possible to automatically detect anomalous connections, e.g. when connections are made from unusual source addresses or when they are made at unusual times. Data collected by PrivX is used for training the UEBA to distinguish normal and anomalous connections. Results are based on customers' own data used in training. UEBA focuses initially on connection metadata, enabling alerting/blocking anomalous connections.

​​​​​​​High-level steps for UEBA setup involve:

1. UEBA-server setup.
2. Training UEBA to distinguish normal/anomalous connections.
3. Configuring anomaly thresholds and behavior.

 

Real-time SSH Connection Monitoring

Sometimes it is mandatory to survey what is being done in real-time. Now it is possible to start live connection monitoring, for example, when third parties are making changes to critical systems, handling privacy-related files, a connection needs to be shared in training situations, etc.

 

PrivX as an OpenID Connect Provider

OpenID Connect is the de-facto standard for handling authentication in the modern world. The OIDC Provider performs user authentication, user consent, and token issuance. The client or service requesting a user’s identity is normally called the Relying Party (RP).

PrivX 2.4 (2018) introduced the Relying Party functionality, meaning that it has been possible to log into PrivX using a single-sign-on (SSO) solution which supported OpenID Connect Provider functionality. Such solutions are provided by e.g. Okta, Google, Sailpoint, Forgerock, etc.

Now, PrivX can also work as an OIDC Provider. In other words, it can perform user authentication and issue tokens/claims for accessing applications supporting OIDC-relying party functionality. Users can access web applications by logging into PrivX. Application-specific login credentials are not needed. Connections are not going through PrivX (no session recording).

 

In addition to the features described above:

• Additional container support for Web carrier: Firefox, Firefox Lite, Chromium Lite
• Hostname as a parameter to password-rotation scripts
• Utility for cleaning up old daily backups
  
  

We also made a bunch of improvements and bug fixes.

 

For more details about the PrivX 26 release, read the full release notes.

This release is mainly a housekeeping release, focusing on improving product quality and architecture. In addition to improving old functionality and fixing bugs, we included a feature for restricting the commands used in SSH sessions.

 

In general, when providing access to target systems whether they are servers, applications, etc., you should:

• Make sure that only the right persons have access to the right resources (this applies to non-human users as well)
• Make sure that they have the right level of access rights (Just-Enough-Access, JEA)
• Make sure that they have access only when it is needed (Just-In-Time, JIT)
• Automate processes to avoid human errors

By default, PrivX has been designed for this. When it comes to accessing critical systems it is important to control what users can do on target systems. The recommended way to control what users are allowed to execute on target hosts is to implement proper access control and separation of duties using target system user accounts, groups, file system permissions, and sudoer configurations.

​​​​​​​However, sometimes re-configuring the target server is not possible or - due to the temporary nature of the need for access - it is not feasible. In such cases, the SSH command restrictions feature can be used to restrict the commands a user is allowed to execute when connecting to the target host through PrivX. The feature can also be used when the execution of commands should not be restricted, but certain commands should trigger alerts. This can be achieved by forwarding audit events to an external SIEM system. Command restriction is done through white lists. When SSH command restrictions are set, users may only perform whitelisted commands.

Restricting SSH commands might sound like a simple task to do, but because of the nature of SSH connections, it is actually quite difficult. It is impossible to reliably distinguish shell commands from program input/output by only inspecting SSH connection (stdin/stdout/stderr streams). One way to do the command restriction/filtering is to use agent software on target systems. The agent could control what commands the shell can execute and what files it could open. The downside is that this requires target server reconfiguration and target server OS/CPU architecture-specific agent binary to be developed, installed, and maintained.

We wanted to avoid this kind of configuration and maintenance burden on target systems. We have found a way to do the command restrictions on the gateway level in a secure way (agentless) and applied a patent for the solution.

 

For more details about the PrivX 25 release, read the full release notes.

In this release we have improved PrivX functionality in multiple areas:

• Real-Time Auditing SSH Connections
• Login to PrivX with a JWT token from a trusted token provider
• Displays certificates configured in PrivX
• Import filter for SCIM directory
• ICAP antivirus checks for file transfers using SFTP

In some situations, it is important to get real-time visibility of the content inside the SSH connections. PrivX can be configured so that it will send SSH events to the audit log. Supported SSH event types to audit are stdin, stdout, stderr, channel_request, and global_request. Output can be then integrated into the SIEM system for automatic event handling. 

Users, whether they are human or non-human, can log into PrivX using multiple authentication methods (LDAP, Azure AD, OIDC, Public-Key, Client-Certificate, etc.).

In addition to the existing methods, it is possible to use an external identity provider to issue and exchange a PrivX access token with a trusted external JWT token.

This can be used especially in machine-to-machine connections.

Certificates have different life cycles, and it is important to renew the needed certificates before they expire. Now it is possible to display Certificates used by PrivX directly from the UI. This helps the admin to identify the certificates which are expired or to be expired soon.

 

Introduction

The main feature of this release is Password Rotation. This helps companies in their journey towards passwordless privileged access management. In addition to that, we have improved some of our existing features:

• Network Target Access was introduced in PrivX 22. Now it is also possible to establish network target sessions to the non-routable targets behind Extenders.
• File scanning with external systems using ICAP can be now done for SSH proxy and native SCP.
• Support for Microsoft Graph as a user directory has been added in this release.
• Additional operating systems supported for host-deployment scripts.
• UI improvements on the PrivX status page.

With PrivX, we have been always promoting certificate-based authentication when providing access to critical resources (see the whitepaper – From permanent credentials to ephemeral certificates).

We want to help companies on their journey to move gradually to passwordless and keyless environments. We also understand there will be always systems where certificate-based authentication cannot be applied, and the security policies require password rotation. We have now introduced the password rotation feature for Linux and Windows accounts. Functionality is built based on password rotation requirements of large banking environments.​​​​​​​

PrivX will automatically rotate passwords:

• Assign a new password to target accounts according to your password rotation policy.
• Automatically store and update the new password to the PrivX vault.

Password rotation policies define:

• How often passwords are rotated.
• The strength of automatically generated passwords.
• Fall-back behavior in case of failures in automation.

Password rotation scripts are Shell scripts, which PrivX runs to rotate passwords on target accounts. In addition to predefined scripts, it is possible to create custom scripts.

 

For more details about the PrivX 22 release, read the full release notes.