Authentication, Access Control and Identity Management

Does PrivX support Multi-Factor/Two Factor Authentication (MFA/2FA) as standard?
Yes, native MFA/2FA is supported as standard. Any Time-Based One Time Password (TOTP) solution will be compatible such as Google and Azure Authenticators, Physical access tokens such as Yubi-Key can also be used.

Does PrivX support role based access management to credentials, administrative functions and features like auditing?
Yes, role based access management is the primary means of governing access rights and permissions within PrivX.

Will I be able to segregate and split administrative duties between different roles e.g. configuration admin, user admin, or site #1 admin and site #2 admin?
Yes, administrative rights and/or actions can be delegated to other roles and their associated users by creating additional PrivX accounts with delegated or limited permission sets.

Can I limit auditor and/or security team focused roles for providing access to audit events only?
Yes, you can limit auditor and/or security team focused roles to only audit events excluding all other permissions. Links to specific session recordings and audit logs can also be provided for ad-hoc review.

Does PrivX support access hierarchies to define access rights to the users?
Yes, access group and associated hierarchy information is fed into PrivX when synchronised/federated with IGA tools and directory services such as AD.

Can I map one account per end user for multiple instances including shared accounts on targets?
Yes regardless of the account used to login into targets, users are mapped back to a single identity and are therefore fully accountable.

Will I be able to remove/terminate access in the event of an emergency?
Yes, roles can be revoked as well as active sessions being terminated by those with appropriate permissions.

How does Ephemeral Certificate/Smart Card authentication work for Windows RDP targets?

When accessing via PrivX GUI

  1. The Windows Active Directory is configured to trust the PrivX CA -> the trust anchor has been imported to the Windows CA on the AD - PrivX acts as a subordinate Cert authority
  2. A user initiates a connection to a target host within the domain 
  3. The RDP proxy component asks our internal CA for an ephemeral certificate 
  4. Authorizer checks the user’s roles and makes a decision if he should be allowed to connect to the target host 
  5. If yes, an ephemeral certificate (valid for 5 mins) with a baked-in principal name is given to the RDP proxy
  6. The certificate is used to authenticate the RDP session to the target host
  7. The target host makes a CRL check to the CRL endpoint defined in the certificate
  8. User is logged in, there are no per-session keys or certificates to be rotated since the virtual smart card certificate used for login is short-lived.

Can I use NLA for RDP connections via PrivX

NLA is not supported for RDP targets with certificate-based authentication. However, NLA may be enabled for RDP targets that only use password authentication.

Instead of relying NLA, best practice is to configure access control to ONLY allow RDP access from PrivX machines to target hosts. With this, RDP access is secured end-to-end as follows:

  • Users authenticate to PrivX with MFA, Passkey, etc.
  • RBAC is enforced.
  • Target hosts only accept RDP access from PrivX.
  • PrivX authenticates with target hosts by ephemeral certificate. This also removes passwords and associated maintenance work.
  • Session recording allows 4-eyes monitoring.

Was this page helpful?