Every company has its own IT landscape: identity providers, certificates, automation tools, and security policies. Axidian Privilege 3.4 makes it easier to fit privileged access protection into this existing setup, without changing how teams already work.
Key updates of this release include login through external Identity Providers and X.509 certificates, secure use of privileged credentials in Ansible and Python, Kerberos support in RDP Proxy, and reports that run in the background.
Login through external Identity Providers:
one sign-in experience across company systems
Axidian Privilege 3.4 supports login through an external Identity Provider using the OpenID Connect protocol. Users sign in to both the Management Console and the User Console with their email address.
Why it matters
Many companies already use single sign-on (SSO) and multi-factor authentication (MFA) for their business systems. Axidian Privilege now connects to this existing setup, so users log in the same way as they do everywhere else in the company, and the same MFA rules apply.
Administrators also do not need to set up and maintain a separate login method just for Axidian Privilege, which reduces their workload.
Certificate-based login:
strong authentication with the company’s existing PKI
Users can now sign in to the Axidian Privilege consoles with X.509 client certificates. This is especially relevant for organizations that use a corporate PKI.
Why it matters
Companies that already run a PKI can use it to protect access to Axidian Privilege, with no changes to their architecture. Certificate-based login adds one more trusted way to sign in, which raises the level of protection for access to critical resources.
Organizations get stronger security by building on technologies they already have, instead of introducing new ones.
Ansible support:
secure automation without exposing passwords
Axidian Privilege 3.4 expands its integration with Ansible, so playbooks can use privileged credentials securely in two ways. They can retrieve passwords and SSH keys from Axidian Privilege through a Lookup Plugin, or connect to target resources through SSH Proxy.
Why it matters
Automation scripts often need passwords and keys to do their work. When these secrets are written directly into scripts or configuration files, they are hard to control and can easily leak.
With this integration, operations and DevOps teams keep working in the tool they already know, while the secrets stay inside Axidian Privilege. The security team keeps control over access, audit records, and full visibility into how critical credentials are used.
PAM Servers widget:
server problems found before they affect users
Version 3.4 introduces health monitoring for servers, components, and services. Axidian Privilege automatically checks whether key infrastructure nodes are available, and shows the results and any error messages in a new PAM Servers widget on the dashboard.
Why it matters
Administrators see the state of the whole installation in one place, without checking each server separately. They can find a problem server faster and fix failures before they affect users’ access to critical resources.
Kerberos in RDP Proxy:
full compatibility with strict Windows security policies
Axidian Privilege now supports Kerberos authentication in RDP Proxy connections to target resources.
This is important for organizations that follow modern Windows security policies, with Network Level Authentication (NLA) enabled and NTLM disabled.
Why it matters
Many companies use these strict settings to protect their Windows infrastructure. In such environments, a connection through a proxy needs Kerberos to work without exceptions to the security rules.
With version 3.4, Axidian Privilege can be deployed in these environments without weakening any security settings. Companies keep the same login standards everywhere, and Axidian Privilege serves as a controlled entry point to privileged resources.
Python SDK for credential access:
secure passwords for applications and scripts
Axidian Privilege 3.4 includes a Python SDK for programmatic access to credentials. It allows Python applications, automation scripts, CI/CD pipelines, and orchestration systems to retrieve passwords and SSH keys from Axidian Privilege securely.
Why it matters
Developers no longer need to build their own integrations or keep passwords inside their code. This makes it easier to bring PAM into existing development and operations processes.
All secrets stay in one central place, under the same security rules as any other privileged access.
Reports run in the background:
administrators keep working while reports are prepared
Reports on permissions, sessions, and events are now generated in the background. Completed reports are available in the new Report History section and can be downloaded in CSV, XLSX, or PDF format.
Why it matters
Administrators do not need to wait for an export to finish or put other tasks on hold. They can start a report, continue their work, and download the result when it is ready.
This makes it faster to prepare for audits, collect data for incident investigations, and create internal reports.
Personal sign-in for the ConsoleApp utility:
every action linked to a specific person
Users can now sign in to the ConsoleApp utility as a specific Axidian Privilege user. At the same time, sign-in with a service account remains available, so organizations can combine personal and service-based workflows, depending on their internal security policy requirements.
Why it matters
With personal sign-in, each employee works in ConsoleApp with their own permissions, and every action is recorded under their name. This gives the security team a clear picture of who did what and makes audits more precise.
Personal sign-in also allows more precise separation of access rights: each employee gets only the permissions they need for their tasks.
Login formats for SSH connections:
fewer connection errors in mixed infrastructures
Administrators can now define login formats for local and domain accounts in SSH connections, for example user, DOMAIN\user, or UPN (user@domain). The format can be set in the user’s connection settings or in the resource profile.
Why it matters
In large infrastructures, different systems often expect usernames in different formats. If the format is wrong, the connection fails, and someone has to fix it by hand.
With predefined formats, connections to Linux servers and network devices work as expected for both users and administrators. There are fewer errors and less manual configuration.
SSH connections without PTY:
easier automation and network device access
Axidian Privilege now supports SSH connections without a pseudo-terminal (PTY). A pseudo-terminal is the interactive command window that a person normally types in. Scripts and many network devices do not need one, and some devices do not support it at all.
Why it matters
SSH can now run in non-interactive mode, which is important for automation, running batches of commands, and connecting external tools. Network devices and other systems that do not support PTY are also easier to work with.
As a result, Axidian Privilege becomes even more convenient, not only for everyday administration but also for automated operations, and all these connections stay under its control.
Access server details in sessions and events:
faster diagnostics and investigations
Session and event details in Axidian Privilege now show which access server the session went through.
This is especially useful in infrastructures with load balancers and several access servers, where the route of each connection is not always obvious.
Why it matters
Administrators get more context when analyzing connections and can see at once through which server a user gained access. If an error or suspicious activity occurs, they can find the problem area faster and spend less time on diagnostics and investigations.
