The recommended PrivX integration to access Resource Domains' member hosts in a multi-domain environment is to use a centralized Account Domain. The separate Windows domains must have at least one-way trust so that the Resource Domains trust the Account Domain that has the admin user accounts granting access to the environment.
This simplifies the deployment when PrivX users authenticate against a single domain Windows Active Directory instead of each separate AD in different domains with potential user account collisions and unnecessary duplication of accounts. Also, only one Enterprise CA setup is required instead of Forest-wide Enterprise CA or Enterprise CAs in each separate domain. Furthermore, the target resource domains can be configured with intended authorized access for Account Domain users without the need to consolidate existing practices in each domain that can co-exist with PrivX and be later phased-out or used as a break-glass method.
A shared user account on the target could be used with certificate authentication for some or all users as well if desired. The instructions below assume PrivX users login as self to target hosts to have complete user audit information also on the target host instead of just in PrivX (or PrivX logs in SIEM) that shows both the shared account and the actual user account for the login. Using a shared account would need changes to RDP session configuration on the target if multiple users will be using same shared account to same target host simultaneously.
Account Domain Prerequisites
1. Trusted Account Domain must include:
A Domain Controller with the server role Active Directory Domain Services, for handling authentication requests. The DC must identify itself with a valid Domain Controller Certificate with proper extended key usages enrolled from the Enterprise CA of Account Domain using for example Kerberos Authentication template with:
EKU OID 1.3.6.1.5.5.7.3.1 Server Authentication
EKU OID 1.3.6.1.5.5.7.3.2 Client Authentication
EKU OID 1.3.6.1.4.1.311.20.2.2 Smart Card Logon
EKU OID 1.3.6.1.5.2.3.5 KDC Authentication
A Certificate Authority Server (Enterprise CA server), with the server role Active Directory Certificate Services, including the role service Certificate Authority.
The Enterprise CA (on same server or dedicated server) must also have a service for certificate-revocation-status checks of the domain controller certificate(s) that is accessible from other domains, for example, HTTP CRL with Certificate Enrolment Web Service or Web Server IIS role, or alternatively OCSP with the Online Responder role service.
2. Both the domain controller and the Enterprise CA server must run on one of these supported platforms (with the latest service pack and updates):
Windows Server 2008 R2
Windows Server 2012 R2
Windows Server 2016
Windows Server 2019
3. The domain policy must enable server certificate auto-enrollment. For instructions about enabling this, please refer to Microsoft documentation at https://docs.microsoft.com/ (search: configure server certificate autoenrollment).
4. Firewalls for the domain must allow HTTP access to PrivX server port 80, for obtaining the Certificate Revocation List for validating the user certificates.
5. Domain Controller must be able to resolve PrivX server FQDNs.
6. To enable users to log in with their own user accounts, ensure that the users have the appropriate UPN (User Principal Name) in windows_username attribute. Note that if logon UPN is not implicit (e.g. user@accountdomain.company.com) but instead explicit (e.g. user@company.com) with additional domain suffix in the Windows environment, then one-way trust must be configured as a Forest trust instead of External trust.
Resource Domain Prerequisites
7. Trusting Resource Domain and target hosts must have access and means to authenticate the Account Domain's domain controller and allow access to appropriate Account Domain users.
At least one-way outgoing trust to Account Domain
Name suffix routing if explicit UPNs are used in the environment (e.g. user@company.com) instead of implicit (e.g. user@accountdomain.company.com). Routing is automatically set if Forest type trust is configured.
Ensure that users' group policy allows RDP login. When enabling login with personal accounts, also ensure that the target host local policy allows users to log in locally.
Ensure NLA is disabled on target hosts as smart card device channel in RDP has to be established before the certificate authentication can occur.
8. The local domain controller must run on one of these supported platforms (with the latest service pack and updates):
Windows Server 2008 R2
Windows Server 2012 R2
Windows Server 2016
Windows Server 2019
9. Firewalls for the domain must allow HTTP access to PrivX server port 80, for obtaining the Certificate Revocation List (CRL) for validating the user certificates and to Account Domain's Certificate Revocation Service e.g. port 80 for HTTP CRL for validating the domain controller certitificate(s). The PrivX instance must be able to connect to the port 3389 on the target hosts either directly or via PrivX Extender.
10. Hosts in the target domain must be able to resolve PrivX server FQDNs and Account Domain's DC and Certificate Revocation Service server's FQDNs.
11. To enable users to log in with their own user accounts, ensure that the users have the appropriate UPN (User Principal Name) in windows_username attribute. If the configured user directory is directly Windows Account Domain Active Directory and users log in to PrivX with UPN, this is usually correct. Mapping of the attribute is needed if other user provider, for example OKTA, is used in between PrivX and Account Domain. Use the OKTA scope profile and attribute mapping upn=windows_account in PrivX.
12. For the target host (in PrivX) add an account with Use user's personal account checked with a suitable role configuration, for example windows-admin role configured with (memberOf=CN=winadmin,CN=Users,DC=accountad,DC=company,DC=com) to an Account Domain's Active Directory group that has appropriate users as direct members.
Account Domain Configuration
1. Ensure Account Domain prerequisites are met.
2. Download the PrivX CA certificate from PrivX Settings > Deployment > Configure a Windows domain for RDP access and transfer it to the Windows Account Domain's domain controller.
3. On the Windows domain controller, import the PrivX CA certificate using the instructions below:
Start the Group Policy Manager
Open Forest → Domains → [your domain] → Group Policy Objects
Right click and edit the Default Domain Controllers policy
Open Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certificate Authorities and then right click and import the certificate
For improved security also restrict the purposes of the PrivX CA. In the general properties of the PrivX CA certificate, select Enable only the following purposes and then select the following purposes: Smart Card Logon and Client Authentication. Save the changes to the certificate.
4. Publish the PrivX CA certificate as trusted in the domain by entering the following commands at the command prompt:
certutil -dspublish -f privx_ca.crt NTAuthCA
certutil -enterprise -addstore NTAuth privx_ca.crt
Resource Domain Configuration
5. Ensure Resource Domain prerequisites are met.
6. Download the PrivX CA certificate from PrivX Settings > Deployment > Configure a Windows domain for RDP access and transfer it to the Windows Resource Domain's domain controller.
7. Obtain the Enterprise CA certificate of Account Domain, for example export from Account Domain's domain controller or download from AIA (Authority Info Access) URL if available in Account Domain's Domain Controller Certificate.
8. On the Windows domain controller of the Resource Domain, import both PrivX CA and Enterprise CA certificates using the instructions below:
Start the Group Policy Manager
Open Forest → Domains → [your domain] → Group Policy Objects
Right click and edit the Default Domain policy
Open Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certificate Authorities and then right click and import the certificates
For improved security also restrict the purposes of the PrivX CA. In the general properties of the PrivX CA certificate, select Enable only the following purposes and then select the following purposes: Smart Card Logon and Client Authentication. Save the changes to the certificate.
9. Publish only the Enterprise CA certificate as trusted in the resource domain by entering the following commands at the command prompt:
certutil -dspublish -f account_domain_enterprise_ca.crt NTAuthCA
certutil -enterprise -addstore NTAuth account_domain_enterprise_ca.crt
10. In PrivX, configure the RDP target host with an RDP service and configure the accounts and corresponding roles that are allowed to access the host.
11. Wait for Default Domain policy to get propagated to target host or run on the target host:
gpupdate /force
and ensure the appropriate CA certificates are available locally in NTAuth:
certutil -viewstore -enterprise NTauth