Hitachi ID Systems suggests the following approach for external access to on-premises systems (e.g., by vendors and similar users):

  1. Create either a separate directory or a container in the existing Active Directory, where accounts for vendor users will be kept.
  2. Create a sub-container for each vendor.
  3. Manage user accounts for vendor staff in each container.
  4. Create one group per vendor. Attach vendors accordingly.
  5. Deploy a session proxy that vendor users will use to establish login sessions to managed systems. Hitachi ID Privileged Access Manager supports two approaches to such proxies:
    1. VDI session proxy:
      • Deploy Microsoft Remote Desktop Services or Citrix servers.
      • Vendor users first connect to the VDI server.
      • From a session on a VDI server, vendor users sign into Privileged Access Manager.
      • Using Privileged Access Manager, vendor users launch sessions to managed systems.
      • All relevant administration tools are installed on the VDI servers -- PuTTY, SecureCRT, Terminal Services Client, vSphere, SQL Studio, etc.
    2. HTTPS/HTML5 session proxy:
      • Deploy Privileged Access Manager Linux/Tomcat/Guacamole proxy servers.
      • Vendor users sign into Privileged Access Manager on an Extranet URL.
      • Using Privileged Access Manager, vendor users launch sessions to managed systems.
      • Sessions are rendered on the user's browser in a separate browser tab, in an HTML5 Canvas.
      • Actual SSH and RDP sessions are established from the Guacamole proxy to the managed system.
      • As the display of the SSH or RDP session evolves, updates are sent to the user's browser as a series of small PNG images that are overlayed on the canvas in real time.
  6. Using multiple authentication factors and a CAPTCHA to authenticate users connecting from the Internet is strongly recommended. Privileged Access Manager supports no-cost 2FA and CAPTCHA integration out of the box.
  7. Do not pre-authorize vendor users for any access. i.e., they can request access, but all requests must be manually approved.
  8. Do record all activity in sessions initiated by vendors -- keylogging, screen capture, etc. -- to create a detailed audit trail and strong accountability.
  9. Allow system/application owners to monitor vendor login sessions both in real time and after the fact. System/application owners should have the ability to terminate sessions in real time, if they see a vendor user doing something wrong.
  10. Notify vendors at login time that their sessions are being recorded and may be monitored.


The HTTPS/HTML5 proxy approach to vendor access is illustrated in Figure [link].

Architecture for Remote Access using HTTPS/HTML5 Proxy

Architecture for Remote Access using HTTPS/HTML5 Proxy

In the figure:

  1. A user working for a vendor connects to Privileged Access Manager using a reverse web proxy, located in the DMZ. This proxy forwards HTTPS connections from the user's browser first to the on-premises Privileged Access Manager server and later, at session initiation time, to the on-premises session proxy.
  2. The user signs into the Privileged Access Manager web portal, typically by responding to a CAPTCHA and then providing two or more credentials.
  3. The vendor's user requests access to a managed endpoint. This is typically not pre-authorized, so a workflow request is created, inviting the Internal user to approve the access (SMTP - not shown), which he does (HTTPS - not shown).
  4. Once the internal user has approved access (to a specific account on a specific system during a specific time interval), the vendor's user can launch a login session. The actual session is from the proxy to the managed system, but it is displayed in the user's browser in a new tab, as an HTML canvas. No client software (other than the browser) is installed on the user's PC (or phone, or tablet).
  5. Both session metadata and video/keylog data are captured, archived and may be monitored by authorized users, typically on-premises or via VPN.

User Experience

The user experience of remote vendor users signing into on-premises systems and applications is as follows:

  1. Customer calls vendor, requesting assistance.
  2. Vendor assigns an employee to do the work.
  3. Customer verifies that this vendor-user already has an AD account.
    • If not, create the new AD account and trigger discovery on Privileged Access Manager.
    • Management of vendor accounts in the relevant OU, including request, approval, periodic recertification, password resets and more can be delegated to one or more key users at each vendor, using Hitachi ID Identity Manager and Hitachi ID Password Manager (with Hitachi ID Identity Express: Partner Portal Edition).
  4. Depending on which type of proxy was used, the vendor user login experience will vary:
    1. VDI session proxy:
      • Sign into a VDI session.
      • Launch a browser to sign into Privileged Access Manager.
      • Respond to a CAPTCHA and two credentials.
      • Search for, find and request access to the required managed account.
      • Wait for approval by the system/application owner.
      • Launch a login session with the relevant administration tool.
    2. HTTPS/HTML5 session proxy:
      • Sign into Privileged Access Manager with the user's own browser, on his own endpoint.
      • Respond to a CAPTCHA and two credentials.
      • Search for, find and request access to the required managed account.
      • Wait for approval by the system/application owner.
      • Launch an SSH or RDP session, which will be visible in a second browser tab.
  5. When finished work, the vendor user will check-in access, which normally causes all still-open sessions to terminate and the password for the managed account to be randomized and vaulted again.
  6. At any time, application/system owners may monitor session activity and/or terminate the session.
  7. After the fact, application/system owners and auditors can search for, retrieve and watch previously recorded session activity.