Skip to main content

Integrations

The integration module is the only part of Bastion Pass that depends on the protected system. In any system, it does three things:

  1. detects the start of each connection, with the user and source IP;
  2. asks Bastion Pass whether the connection may go on;
  3. closes the connection when the answer is no.

The portal, authenticator enrollment, policies, risk analysis and audit trail are the same from one system to another.

Microsoft RD Gateway​

The RD Gateway integration protects RDP access made with Remote Desktop Connection (mstsc) or any client compatible with the gateway.

The module is installed on the NPS server that RD Gateway already uses as its central authorization policy server. Nothing is installed on the gateway servers, and a farm with several gateway nodes is served by the same NPS.

The gateway's own policies still apply. The connection authorization policy (CAP) and the resource authorization policy (RAP) decide, as today, who may use the gateway and which servers they may reach. Bastion Pass adds the second factor to that decision.

For the user, a connection without an unlock opens and is closed within 2 seconds, with the Windows disconnection message. The user unlocks access in the portal and connects again.

Environment requirements​

  • RD Gateway with its authorization policies pointing to a central NPS server.
  • Active Directory, used by the gateway and by the portal to check the password.
  • A Linux server with Docker for Bastion Pass and a PostgreSQL database.
  • The portal published on the same outbound network (DMZ) as the gateway.
  • Target servers that accept RDP only from the gateway. Without that rule, a direct connection to a server would skip the second factor.

Other systems​

The same model works for systems whose client cannot ask for a second factor, for example:

  • a legacy Java application with a desktop client, where the module sits at the point where the server accepts the login;
  • systems with a proprietary client that authenticate against a central server.

To build an integration, the system must expose, at the start of each connection, the user and the client IP, and allow that connection to be denied or closed. That point can be in the application itself, in the application server, or in a component in front of it, such as a gateway or proxy.

Each case is assessed with the GuardianKey Customer Success team, who points out where to install the module and what needs to be developed.