Skip to main content

Bastion Pass

Bastion Pass is the GuardianKey Auth Bastion module that brings multi-factor authentication to systems whose client has no place to ask for a second factor. The most common case is remote access to Windows with Remote Desktop Connection (mstsc) through RD Gateway: the client asks for a username and password and has no screen for a verification code.

The problem​

Bastion Web, the other Auth Bastion module, protects web systems by sitting between the browser and the application. It intercepts the login and asks for the second factor before granting access. That model depends on a browser.

RDP, desktop clients and legacy applications with their own client never go through a page where the bastion could add that step. Changing the client is rarely an option: it belongs to a third party, the source code is not available, or replacing it would mean touching every workstation in the company.

The idea: unlock access through a parallel channel​

Bastion Pass separates strong authentication from the use of the system.

Before connecting, the user opens the Bastion Pass portal in a browser. They sign in with their company username and password (the same directory the protected system uses) and confirm with the code from their authenticator app. The portal records an unlock for that user, from the IP address they came from.

After that, the user works with the system as usual. On every new connection, an integration module installed next to the protected system asks Bastion Pass whether there is a valid unlock for that user coming from that IP. If there is, the connection goes on. If there is not, the connection is closed and the user has to go through the portal.

Neither the protected system nor the client the user already has changes. What gets installed is the portal and the integration module.

What changes for the user​

On first access, the user enrolls their authenticator app (Google Authenticator, Microsoft Authenticator or any TOTP-compatible app) by scanning a QR code in the portal.

When connecting from a new IP, they go through the portal and enter the code. On the same screen they can check "Trust this IP": the unlock then lasts 30 days. Without it, the unlock lasts 12 hours and renews with each use, up to a limit of 24 hours. Both periods are configurable.

From the same IP, while the unlock is valid, there is no extra step. The system opens as before.

What comes from Auth Bastion​

Bastion Pass has no user registry or administration of its own. It uses what is already configured in Auth Bastion:

  • the users' TOTP enrollment, including resets done by the administrator;
  • the user and IP policies, to allow or block users and networks without going through the portal;
  • the risk analysis from GuardianKey Auth Security, checked at portal login and on every connection to the system;
  • protection of the login form against automation and brute force with GKTinc.

Every decision, in the portal or on a connection, is recorded in an audit trail.

Where it can be used​

The first available integration is with Microsoft RD Gateway, for RDP access through mstsc. It does not require installing anything on the gateway servers.

The same model works for other systems whose client cannot handle a second factor, such as a legacy Java application or a proprietary desktop client. For each system only the integration module changes, that is, the point where the system checks Bastion Pass on each connection. The portal, enrollment, policies and audit trail stay the same. The feasibility of each integration is assessed with the GuardianKey Customer Success team.