Authentication

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.

What happens to the ephemeral/short lived certificates after they have expired?

Ephemeral certificates expire after a period of 5 minutes by default. In Windows environments
the expired certificates are held within the expired certs store of the target machine which can be scheduled to be periodically purged via group policy. For SSH connections on the other hand the certificates are not stored after expiry as the target side cert is already present on the target machine (in the form of a .pub file) and is purely checked in order to authenticate, the unique issuing certificate (server side) is automatically purged within PrivX.

If an SSH connection is authenticated via PrivX Agent, do the role private keys ever leave the PrivX server

No. When making a connection, the privx-agent on the client machine authenticates to PrivX and requests for credentials for a specific host. PrivX returns a list of public keys according to user's role configuration and the agent passes the list to the ssh client.

The ssh client proposes each public key to the target server. If the server accepts a key, the client requests the privx-agent to create a signature using the private key and privx-agent forwards the request back to PrivX. The signature is returned back to the client and the connection is authenticated.