Configuration of Oplon Secure Access

In this part of the guide, aimed at all administrators of the Oplon suite, we describe the fundamental concepts of Oplon Secure Access and how to configure new resources to be accessed by third parties.

At the end of the guide you will understand the concepts of User Group and Resource and you will be able to create your first resource of type Host or Web App/Link.

Prerequisites

1. You have already installed and configured the appliance as described here.
2. You have configured MFA as described in this guide.
3. (Optional) If you want to use File Managing on Windows resources, install OpenSSH Server on each resource:
   • Microsoft guide  for Windows ≥ 10 and Windows Server ≥ 2019
   • Win32-OpenSSH guide  for earlier versions

Fundamental concepts

Within OSA there are a few fundamental concepts that are worth explaining:

User Groups

User Groups represent a class of users all having the same privileges: they are the labels used to associate resources (Hosts / Links) to users.

A User Group has a unique name and a description. The User Groups defined in Oplon Secure Access bind to the User Groups defined in MFA — as described in this guide — so that every user registered in Oplon MFA is granted exactly the intended privilege.

Resources and Locations

In Secure Access a Resource is an entity that can identify:

• a Host (Windows, Linux, macOS)
• a Remote App
• a Web App/Link

Each resource can be cataloged through a Location, a label used to logically group the resources of the configuration.

Hosts

A Host is the representation of a machine (physical or virtual) identified by its IP address/hostname. A Location can be assigned to a Host for logical grouping and to represent the resource in an orderly, hierarchical way inside the Oplon Secure Access user interface.

Different types of access can coexist on a Host:

• SSH
• RDP
• Remote App (RDP)
• VNC
• SFTP (File manager)

These accesses can be assigned to the various User Groups according to the desired policies. It is also possible to define predefined OS login/AD login values, so that the user does not have to enter a username or a password.

Remote App

Remote Apps (RDP only) are child entities of a Host and allow exposing single applications through the RDP protocol.

Web Apps/Links

A Web App/Link is a resource represented by a URL. It can be accessed through Oplon Secure Access:

• in native HTTP/HTTPS mode
  • mediated by Oplon’s Reverse Proxy (with MFA authentication)
  • published on the internet
• in Browser Isolation mode (see here)

Both can be resources internal or external to the infrastructure. Native mode requires significantly fewer resources than Browser Isolation, which needs dedicated appliances but offers a higher level of security and segregation.

Shared Folders

Shared Folders allow mounting, via the Oplon Client (Windows, Linux, macOS), network drives protected by the platform (MFA, ZTNA, policies). Access is always authenticated and authorized based on the assigned User Groups and configured policies.

Currently the supported protocol for mounting is WebDAV: the share is exposed to the client as a drive or mount point and all file operations are mediated and tracked by Oplon.

Trusted Connection

A Trusted Connection opens a secure channel between the user’s workstation and selected backends (e.g. DB servers, Telnet, general applications), without exposing public ports nor the network hosting them. Access is always enforced via MFA, ZTNA and Oplon’s PAM policies.

The connection is established by the Oplon Client and can be published on the workstation in two modes:

• Local Proxy: the single service is reverse‑proxied on localhost on a specific port (e.g. localhost:NNNN);
• NAT: a tunnel towards the remote network is created and the real backend addresses keep being used.

The comparison between the two modes is in Publishing modes: Local Proxy and NAT.

Configuration interface

To set up a new resource, open the Oplon Secure Access administration interface at https://<your-ip>:4444 and log in.

From the left menu open Secure Access > Settings and open the module.

In this screen you can:

• see the list of User Groups, adding new ones and deleting old ones
• manage the list of Hosts
• manage the list of Web Apps/Links

Add a new User Group

To add a new User Group, click the green (+) button of an existing User Group: an empty one will be created and can then be edited.

For each User Group it is possible to enable or disable the permission to use session temporary connections (a feature typically reserved for administrators) and the video recording of the sessions associated with them. Session temporary connections are temporary connections that allow users — belonging to at least one group in which this feature is enabled — to connect to any Host, even in the absence of groups associated with the target resource.

Add a new Host

To add a new Host, click the green (+) button of an existing Host: it will be duplicated and can then be edited.

To modify a Host it is recommended to open the details using the See Details button.

Important fields:

• Hostname / IP
• Name
• Location
• Description
• Services and ports: SSH, RDP, VNC, SFTP (File manager)…
• Any RD Gateway (RDP only)
• The associated User Groups
• Any Remote App (RDP only)

Add a new Remote App

To add a Remote App you must necessarily start from a Host with RDP access already configured.

Go to Secure Access > Settings, open the desired Host and, in the Applications section, enter:

• name: the name that will appear in the user’s menu
• description
• app name: the alias of the app published via RDP
• working dir (optional): the working directory of the app
• args (optional): the app start arguments

Remember to always perform Save and Re‑Init.

Add a new Web App

To add a new Web App, open the Secure Access > Settings interface and scroll down to the Web Apps section at the bottom of the page.

Enter the minimum information needed to use the Web App, i.e.:

• name
• url
• location

Remember to always perform Save and Re‑Init.

Browser Isolation

In addition to the instructions above for the native Web App, to make the Web App available in Browser Isolation mode you must enable the enable Browser Isolation option.

Opening the details with the black arrow at the end of the line gives access to the settings specific to Browser Isolation mode only:

1. enable Browser Isolation: enables Browser Isolation.
2. Whitelisted: whitelists the url entered above. The effect is to block navigation towards every other url, except the url itself and those optionally specified in White Listed Domains.
3. White Listed Domains: when Whitelisted = true, a comma-separated list of addresses not to be blocked. The syntax to follow is <scheme>://<host><path> (here  a more complete guide on the syntax).

Adding a new Shared Folder

To add a Shared Folder just click the (+) button on the dedicated screen.

To modify a Shared Folder it is recommended to open the details using the See Details button.

Configurable fields:

• url: address published through the Oplon ADC (e.g. https://sales.drive.acme.net)
• name: readable name, shown to the user
• assignedUserGroups: authorized User Groups
• description: short description and policy

Remember to always perform Save and Re‑Init.

Firewalling files transferred with Shared Folders

To filter WebDAV files apply two rewrite rules on the ADC route that publishes the Shared Folder:

• LBLHTTPWebDavFileCheckHeader (rewrite header)
• LBLHTTPWebDavFileCheckBody (rewrite body)

Both rules are customizable: by changing the variable WHITE_LIST_EXT you set the list of allowed/blocked extensions (e.g. .exe,.bat,.js). The rules will check headers and/or content of transfers and block disallowed files.

Adding a new Trusted Connection

To add a Trusted Connection click (+) in the Trusted Connections section; the duplicated entry can then be edited. To modify a Trusted Connection it is recommended to open the details using the See Details button.

Configurable fields:

• name: descriptive name of the connection, shown to the user
• endpoint address/CIDR: destination of the connection. In Local Proxy mode it is the address of the single backend; in NAT mode it is the network/subnet published to the client, in CIDR notation
• endpoint PORT: destination backend port
• Trusted Connection Mode: publishing mode on the workstation, Local Proxy or NAT (see Publishing modes)
• tc listener IP: IP on which the Oplon ADC listens for tunnel connections
• tc listener PORT: port on which the Oplon ADC listens for tunnel connections
• assigned user groups: User Groups authorized to use the connection
• location: logical grouping label

Expanding the resource with the black arrow at the end of the line gives access to two additional fields, valid in Local Proxy mode only: upstream address and upstream port (see Local Proxy mode).

Remember to always perform Save and Re‑Init.

Publishing modes: Local Proxy and NAT

The Trusted Connection Mode field determines how the remote service becomes reachable on the workstation. The activation procedure on the user side, instead, is identical in both modes.

In short: Local Proxy is the simplest and least invasive choice when a single service has to be exposed (a database, an internal web console, a host to be reached over RDP); NAT is the right choice when the application has to reach several hosts on the remote network, or when it uses the real addresses and cannot cope with the remapping onto localhost.

Local Proxy mode

This is the default mode. The remote service is exposed on the workstation as a local address: the Oplon Client shows the mapping remote-address:port → 127.0.0.1:port and the user, in their applications, uses the local address instead of the real backend one.

On the resource, therefore, set Trusted Connection Mode to Local Proxy and define the single backend to publish through endpoint address/CIDR (the host address) and endpoint PORT (the service port).

Expanding the resource with the black arrow at the end of the line you can also control the local address exposed on the workstation:

• upstream address (localproxy only): local address on the workstation the client listens on for the service (typically 127.0.0.1)
• upstream port (localproxy only): the corresponding local port. If left empty, it is assigned automatically by the client and shown in the app

No special privileges are required on the workstation: this mode works on every operating system supported by the Oplon Client.

NAT mode

In NAT mode an encrypted tunnel to the remote network is created. The Oplon Client creates a virtual network interface and lists the Reachable destinations, that is the subnets reachable through the tunnel: the user keeps using the real addresses of the remote network, and only the traffic directed to those destinations goes through the tunnel, while the rest of the workstation connectivity is untouched.

On the resource, set Trusted Connection Mode to NAT and enter in endpoint address/CIDR the network to publish in CIDR notation (e.g. 10.20.0.0/24): this is exactly what the client will show to the user as a Reachable destination.

The rest of the NAT configuration is global and lives in the General Settings: the NAT server endpoint (TC Server IP and TC Server Port) and the subnet the Tunnel IPs are assigned from (TC Subnet CIDR).

The end-user behaviour of both modes is described in detail in Oplon Client › Trusted Connections.

User Group assignment

The association of a User Group with a resource is what actually grants access to the users of that group. To assign a User Group to a resource, click the green (+) button and select the User Group from the drop-down menu.

Assigning a resource to a User Group enables/disables a series of privileges and security policies, specific to the type of resource:

• SSH access
• RDP access
• VNC access
• File Manager, and if enabled: Upload, Download, Hypercopy
• remote copy/paste
• Impersonification
• session logging (RDP/SSH)
• virtual printer, audio in/out

Assigning a User Group with Impersonification

Impersonification allows mapping the user’s digital identity (coming from MFA and/or Active Directory) to a specific OS Login/AD Login (e.g. domain or local user) for accessing resources.

Impersonification can come from different sources:

1. MFA: defined in the MFA Manager and to summarize it can be:
   • Global: a single impersonification valid everywhere (e.g. ImpersonificationGlobal).
   • Per Group: specific for group membership (syntax Group::Impersonification).
2. Active Directory: derived from AD integration (ImpersonificationAD).

Priority Rules:

• There can be multiple impersonifications linked to groups (from MFA), but only one for each specific group. (This takes priority over the global one)
• There can be only one AD impersonification. (This takes priority over the global one)
• There can be only one global impersonification (from MFA).

Access Logic (Strict vs Non-Strict) Access control varies based on how the User Group is configured on the resource:

• Non-Strict Mode (No OS Login/AD Login specified in the group): Access is allowed. If an impersonification value is present (checking the group one if Group::Impersonification exists, otherwise checking global or AD if ImpersonificationGlobal/ImpersonificationAD exists), it will be proposed as the username for the session.

• Strict Mode (At least one OS Login/AD Login specified in the group): Access is allowed only if the user’s impersonification value (checking the group one if Group::Impersonification exists, otherwise checking global or AD if ImpersonificationGlobal/ImpersonificationAD exists) corresponds exactly to one of the OS Login listed in the group configuration.

User Group assignment summary table

User Group assignment summary table with impersonification set to true

OS Login/AD Login assignment to a User Group

Once a User Group has been assigned within a Host, we can assign it predefined users who must exist within the host itself (OS Login) or within an Active Directory domain (AD Login).

Both, once populated, contribute to the creation of the Secure Access Vaults; we will have respectively an:

• OS Login Vault for local machine users
• AD Login Vault for domain users

For this part, refer to the following sections and to the vault configuration page.

Here we can insert as many users as those with whom we want to allow access for that specific User Group.

If you also want to store the password, so that the user does not have to know or enter it every time, refer to the following paragraphs.

Password Entry for an OS Login (Host Vault)

To assign the password to an OS Login (assigned to a User Group) of a Host, you must go to the Host Vault section via the menu: PAM Management > Vault Manager > Host Vault

Search for the corresponding resource from the search bar and click the green key button to edit the OS Login Names.

From here, select from the drop-down menu the users for whom you want to enter passwords and fill in the corresponding passwords:

Remember to always perform Save and Re‑Init.

Password Entry for an AD Login (AD Vault)

To assign the password to an AD Login (assigned to a User Group) of a Host, you must go to the AD Vault section via the menu: PAM Management > Vault Manager > AD Vault

Search for the corresponding AD username from the search bar and click the green key button to edit the AD Login Names.

From here it is possible to enter the corresponding password:

Remember to always perform Save and Re‑Init.

Access Schedule

This feature allows you to control when a machine can be accessed or used. The settings are defined in each User Group assigned to the resource. The parameters of the User Group are:

• Enable access schedule: indicates whether to enable the time restriction;
• Time zone: indicates the time zone to which the time restriction applies.

In the User Group details, there is a panel called Access Schedule that defines the access rules.

Configuration parameters

Access logic

• enable = false: no restrictions, access is always allowed (the other parameters do not affect the result).

• enable = true and daily = false: Absolute scheduling. Access is allowed only within a continuous interval between: fromDate + fromTime and toDate + toTime. Example:

  Parameter	Value
  fromDate	2025-10-01
  fromTime	08:00
  toDate	2025-10-05
  toTime	19:00

  Access is valid only from 01/10 at 08:00 to 05/10 at 19:00.

• enable = true and daily = true: Daily recurring schedule. The window is valid only if:

  1. The current date falls between fromDate and toDate
  2. The time falls within the window defined by fromTime and toTime

  Condition	Example	Access logic
  fromTime < toTime	08:00 – 17:00	Access only between 08:00 and 17:00 on the same day
  fromTime > toTime	22:00 – 06:00	Access after 22:00 or before 06:00 (crosses midnight)

Summary table

Network Metrics

The metrics monitoring feature allows you to analyze client network performance in real time and store historical data. The data collected is displayed via an interactive graph in the client interface and sent to the backend for storage and historical analysis.

This feature is designed to:

• Monitor the quality of client–server communication
• Identify latency anomalies and network instability
• Support troubleshooting and performance analysis activities

The metrics are calculated directly by the client and represent the actual network conditions perceived by the user.

Displaying metrics

A time graph is available in the client interface, located in the settings menu under Network Metrics.

A preview of the client’s connection quality is displayed in real time:

• good
• mediocre
• poor

Clicking on the colored chip opens the interactive graph showing real-time metrics for the last 5 minutes or so.

The data shown in the graph are:

• TTR: measures network latency;
• Jitter: measure how stable this latency is over time (connection stability).

Clicking on Show graph meaning opens a section describing the data with the relevant reference values.

In the Oplon Secure Access administration interface at: https://<your-ip>:4444 you can find the metrics for all clients by going to: Running Status > Reports, selecting the DB to which the data was sent and then clicking on User Network Metrics.

General Settings

Besides the configuration of individual resources, Secure Access > Settings > General Settings holds the parameters that apply to the whole installation: session recording, acknowledgment message, behaviour of Shared Folders and Trusted Connections.

Remember to perform Save and Re‑Init once done.

SSH and RDP session recording

These parameters define where session recordings are stored and how long they are kept. Recording itself must be enabled on the User Group assigned to the resource (see User Group assignment): here you only define storage and retention.

• SSH recording path / RDP recording path: path on disk where recordings are written
• SSH free space limit / RDP free space limit: amount of free space to preserve on the filesystem; below this value the platform stops recording, so the disk is not filled up
• SSH max space GB / RDP max space GB: maximum space, in GB, that recordings can take up overall
• SSH rotation days / RDP rotation days: retention in days, after which older recordings are rotated

Connection Acknowledgment Message

This is the acknowledgment message shown to the user before the session opens: typically a confidentiality notice, an acceptable-use policy or a legal notice banner.

• Connection Acknowledgment Message (text/html): the content of the message. It accepts HTML, so it can be formatted with headings, lists and inline styles
• Is Mandatory?: when true, acceptance is mandatory — the session only opens after pressing ACCEPT, while DENY cancels it

<div style="font-family: Arial, sans-serif; font-size: 13px;">
  <h3 style="margin-top: 0;">Confidentiality and trade secret notice</h3>
 
  <p>
    By accessing this remote session, you acknowledge that all information, data,
    documents, images, system configurations and, in general, any content you may
    have access to (<strong>the "Confidential Information"</strong>) constitutes
    trade secrets and confidential information of the system Owner.
  </p>
 
  <p>By proceeding, you undertake to:</p>
 
  <ul>
    <li><strong>Confidentiality:</strong> keep all Confidential Information strictly
      confidential and not disclose it to third parties, directly or indirectly, without
      the prior written authorization of the Owner.</li>
    <li><strong>Limited use:</strong> use the Confidential Information solely for the
      purposes strictly connected with the activity authorized in this remote session,
      any personal, competitive or unauthorized use being expressly forbidden.</li>
    <li><strong>No copying:</strong> not copy, download, record, photograph, export or
      otherwise reproduce the Confidential Information, unless expressly authorized by
      the Owner.</li>
    <li><strong>Security:</strong> take all reasonable measures to prevent unauthorized
      parties from accessing the Confidential Information.</li>
    <li><strong>Return/Deletion:</strong> at the end of the session, delete or return to
      the Owner any copy or medium containing Confidential Information, if generated.</li>
  </ul>
 
  <p>You further acknowledge that:</p>
 
  <ul>
    <li>any breach of the confidentiality and trade secret obligations may entail civil and
      criminal liability, as well as compensation for the damages suffered by the Owner;</li>
    <li>the Owner may record and monitor the remote session for security, audit and rights
      protection purposes.</li>
  </ul>
 
  <p style="margin-top: 15px;">
    By clicking <strong>ACCEPT</strong>, you confirm that you have read, understood and fully
    accepted the terms of this confidentiality and trade secret notice. If you do not intend
    to accept, select <strong>DENY</strong> and the session will be closed.
  </p>
</div>

Browser Isolation Language

• Browser Isolation Language: interface language of the isolated browser presented to the user for Web Apps published in Browser Isolation

Shared Folders (mount parameters)

Parameters governing the behaviour of the WebDAV mount on the Oplon Client side. The default values suit most scenarios: change them only when facing performance issues or when instructed by support.

• Shared Folder Loglevel: verbosity of the Shared Folders engine logs. Raise it only while investigating an issue
• Shared Folder Cache Mode: local file cache mode
• Shared Folder Cache Writeback time: how often cached changes are written back to the backend
• Shared Folder Dir Cache Time: how long the content of a directory stays valid in cache before being read again
• Shared Folder Time out: timeout of the operations towards the WebDAV backend
• Shared Folder Custom Params: additional parameters passed to the mount engine, for particular scenarios

Additional SSH algorithms

Lists of algorithms the SSH gateway must accept in addition to the default ones. They are meant for compatibility with older equipment (switches, appliances, legacy systems) that cannot negotiate modern algorithms.

• SSH Additional Ciphers: additional ciphers
• SSH Additional Key Exchange (KEX): additional key exchange algorithms
• SSH Additional Host Key Algorithms: additional host key algorithms
• SSH Additional Pubkey Algorithms: additional public key algorithms

Trusted Connections (global parameters)

Global parameters of the tunneling service, valid for every configured Trusted Connection.

The first three apply to NAT mode only:

• TC Subnet CIDR: subnet from which the addresses (Tunnel IP) are assigned to the workstations connected in NAT
• TC Server IP / TC Server Port: address and port of the NAT server, that is the endpoint the Oplon Client establishes the tunnel to

The other two govern session duration:

• TC Session TTL (sec): maximum duration of a Trusted Connection session. It is the countdown shown by the client: when it expires the tunnel closes and the user has to request the resource again
• TC Idle Timeout (sec): idle time after which the connection is closed

Kerberos Auth

Oplon Secure Access can authenticate against resources using Kerberos, delegating the authentication to a Kerberos server (e.g. a Windows Domain Controller/KDC) instead of relying on the credentials entered by the user.

To enable it, go to Secure Access > Settings and scroll down to the Kerberos Config section, at the bottom right of the page.

Here you can find the following parameters:

• Kerberos Debug: enables verbose debug logging on the ADC for Kerberos authentication. It is useful to troubleshoot configuration problems and should be enabled only while investigating an issue.
• enable krb5.conf: tells the ADC to take into account the configured Kerberos authentication server. Set it to true and fill in the krb5.conf field below with the correct configuration.
• krb5.conf: the actual Kerberos client configuration, following the same syntax used on Unix/Linux systems. In most cases it is enough to change the realm with your own; for more advanced scenarios you can configure it exactly like a krb5.conf on Linux.

Enabling Kerberos Authentication on RDP

To use Kerberos authentication on RDP accesses, in addition to the configuration above you need to:

1. Set enable kerberos auth on rdp to true in the Kerberos Config section.
2. Configure a connection parameter on the R00_DesktopBridge service: open its Linux OS Start Parameters and change the startup container from desktopgate to desktopgate_k.

Remember to always carry out Save and Re-Init at the end.