Artica RDS Proxy Edition

← Back to the remote-control main section

The RDS Proxy (Remote Desktop Service proxy, also called RDP proxy or RDP bastion) is a gateway between your users and your Remote Desktop servers. 
The real server addresses and service accounts stay hidden, and every session can be logged, recorded and sent to a SIEM.

Users open their usual Remote Desktop client against the Artica appliance.
Artica checks who they are, which servers they may reach, from which networks and at what time, then opens the session to the real server on their behalf. 

The gateway engine is ReDemPtion (rdpproxy). 
Artica adds the policy engine (the RDP Proxy authenticator), the web console, the video conversion and the REST API.

The RDS Proxy status page

Why use a bastion instead of port forwarding

Publishing Remote Desktop servers usually means forwarding TCP port 3389 to each server, or one public port per server (3390, 3391…). 
Users must remember which port leads where, every server is exposed to the Internet, and nobody keeps a record of who connected to what.

With the RDS Proxy, users only know the address of the gateway. 
The servers can have private addresses or names that do not resolve on the Internet: 
as long as Artica can reach them, the users can connect to them through the gateway.

Features

• Policies: 
  Who (local accounts or Active Directory groups) may reach which servers, 
  from which networks and during which time slots.
• Masked credentials: 
  Users log in with a gateway account; the account used on the real server is stored on the appliance and never shown. 
• Active Directory: 
  Authorize AD groups of users and publish AD groups of computers.
• Second factor (TOTP): 
  Require a one-time code from an authenticator app, per policy.
• Kerberos NLA: 
  Domain workstations that require NLA sign in with their Kerberos ticket, on a dedicated listener (Artica license).
• Decoy targets: 
  Fake targets in the selector catch a stolen account.
  Opening one raises a SIEM alert and blocks the source address for 24 hours.
• IT charter: 
  Users accept an IT charter before reaching a server.
  Each answer is logged with a fingerprint of the text.
• Custom look: 
  Company colors, logo and a welcome text on the gateway screens (Artica license).
• Session rights: 
  Allow or block the clipboard, drives, printers, smart cards, serial ports and sound per policy.
• Session recording: 
  Record sessions and download them as MP4 videos.
• Live sessions: 
  See who is connected to what, and disconnect a session.
• Access events: 
  Every refused connection is logged with its reason.
• SSH targets: 
  Open a terminal on Linux servers and Artica appliances from the Remote Desktop client.
  Commands are recorded and checked by patterns, and files go both ways.
• Web applications (WebView): 
  Publish one web application in the Remote Desktop session, rendered on the bastion.
  Allowed sites, automatic sign-in, copy and paste, upstream proxy or PAC file per policy.
• Tunnel agents: 
  Reach RDP and VNC servers that the bastion cannot reach, through an outbound connection opened by an agent on the server.
  No inbound port on the remote site, Windows service and MSI package.
• SIEM: 
  Stream authentications and sessions to an Artica SIEM.
• REST API: 
  Manage members, targets, policies and sessions from scripts.

Install the RDS Proxy service

1. On the left menu, choose Your system » Features.
2. In the search box, type RDS.
3. Click Install on the RDS Proxy row.

After the installation, RDS Proxy appears in the left menu. Its status page shows two services, both of which must be running:

• RDP Proxy: the Remote Desktop gateway itself (ReDemPtion).
• RDS policies service (RDP Proxy authenticator): the policy engine that allows or refuses each connection.

Keep the service up to date: see How to upgrade or downgrade the RDS Proxy service. 
Video recording requires an RDS Proxy package built with video support.

Quick start

1. Choose the certificate presented to the users: Service settings » Transport Layer Security.
2. Declare the servers users will reach: Targets.
3. Create the gateway accounts, or authorize Active Directory groups: Members.
4. Create a policy that links members, targets, networks and schedules: Policies. 
   A policy without a network refuses every connection.
5. Connect with any Remote Desktop client to the appliance address (port 3389 by default) using a member account.

Administration pages

Troubleshooting

• NLA authentication failed
• Connection error on Windows 7 or Windows XP
• “Please prepare credentials before connecting”
• Connect directly to a target
• Display only the RDS sessions on a wall screen

FAQ

Are brute-force attempts blocked?

Every refused login is written to the access events with its reason, and can be sent to your SIEM. When a policy requires the second factor, five wrong codes in a row lock the account for 15 minutes. The RDS Proxy is not connected to Fail2ban: restrict the source networks of each policy and use the second factor for accounts reachable from the Internet.

Can I give someone temporary access?

Yes. Each member has an end-of-life date; after that date the account can no longer log in. The Members tab shows the accounts that expire within 15 days.

Can I filter remote addresses by country?

Not in the RDS Proxy itself. Restrict the source networks of each policy, or filter at the firewall in front of the appliance.

Can I manage the RDS Proxy with a REST API?

Yes: see REST API.