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 Cert/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.