Configuration of Oplon Secure Access

This part of the guide, aimed at administrators of the Oplon suite, describes the fundamental concepts of Oplon Secure Access and how to configure new resources so that third parties can access them.

By 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 with the same privileges and are used to associate resources (Hosts/Links) with users.

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

Resources and Locations

In OSA, 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.

Hosts

A Host is the representation of a machine (physical or virtual) identified by its IP address/hostname. You can assign a Location to a Host: it only serves as logical grouping and to represent the resources in an orderly and hierarchical manner in the user interface of OSA.

Different types of access can coexist on a Host:

• SSH Access
• RDP Access
• Remote App Access
• VNC Access
• SFTP Access (File Manager)

These access types can be assigned to the User Groups according to the desired policies.

You can also define predefined OS Login/AD Login entries, so that when accessing that specific Host, the user does not have to enter a username or password.

Remote App

Remote Apps (RDP only) live inside a Host, but are still considered separate resources. They allow you to expose individual applications via the Windows RDP protocol.

Web Apps/Links

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

• in native HTTP/HTTPS mode
  • through Oplon’s Reverse Proxy (with MFA authentication)
  • published on the Internet
• in Browser Isolation mode.

In both cases, the resources can be either internal or external to the infrastructure; different configurations give different results. Native mode requires far fewer resources than Browser Isolation mode, which requires 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 or 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 to the remote network is created and the real backend addresses are still used.

The two modes are compared in Publishing modes: Local Proxy and NAT.

Configuration interface

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

In the left menu, open Secure Access > Settings and access the module.

In this screen you can:

• view the list of User Groups, with the possibility of adding new ones and deleting existing ones
• view the list of Hosts, with the possibility of adding, removing and editing them
• view the list of Web Apps/Links, with the possibility of adding, removing and editing them

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, which you can then edit.

For each User Group you can enable or disable the permission to use session temporary connections (a feature typically reserved for administrators) and the video recording of the associated sessions. 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 you can then edit it.

To edit a Host, it is recommended to open its details with the See Details button.

Main fields:

• hostname/ip
• name
• location
• description
• Services and related 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 new Remote App, you must start from a Host with RDP access already configured.

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

• name: the name displayed in the menu
• description
• app name: the alias of the app published via RDP
• working dir: the working directory of the app (optional)
• args: the app start arguments (optional)

Always remember to click Save and Re‑Init at the end.

Add a new Web App

To add a new Web App, open the Secure Access > Settings interface: the Web Apps section is at the bottom of the page.

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

• name
• url
• location

Always remember to click Save and Re‑Init at the end.

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.

From here, by clicking the black arrow at the end of the row, you can access a series of configurations/customizations specific to Browser Isolation mode:

1. enable Browser Isolation: enables Browser Isolation mode.
2. Whitelisted: whitelists the URL entered above. Navigation to all other URLs is blocked, except for the URL itself and any URLs specified below in White Listed Domains.
3. White Listed Domains: here you can enter a comma-separated list of addresses that must not be blocked when Whitelisted is set to true. The syntax to follow is: <scheme>://<host><path> (see here  for a more complete guide to the syntax).

Adding a new Shared Folder

To add a Shared Folder, click the + button in the dedicated screen.

To edit a Shared Folder, it is recommended to open its details with 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 the + button in the Trusted Connections section; the duplicated entry can then be edited. To edit a Trusted Connection, it is recommended to open its details with 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 row 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, however, is the same 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).

By expanding the resource with the black arrow at the end of the row, 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, in endpoint address/CIDR, enter 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 IP addresses are assigned from (TC Subnet CIDR).

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

User Group assignment

It is the association of a User Group with a resource that gives the users of the group the right to access it. Assigning a User Group to a resource (Host/RDP App/Web App-Link) comes with a series of privileges/security policies, specific to the type of resource assigned, which are listed below. To assign a User Group to a resource, click the green + button and select the new User Group from the drop-down menu, among those already present.

By assigning a resource to a User Group, you can:

• Enable/Disable SSH access
• Enable/Disable RDP access
• Enable/Disable VNC access
• Enable/Disable the File Manager, and if enabled:
  • Enable/Disable Upload
  • Enable/Disable Download
  • Enable/Disable Hypercopy
• Enable/Disable copying (user)
• Enable/Disable paste (user)
• Enable/Disable Impersonification
• Enable/Disable Remote Desktop logging
• Enable/Disable SSH logging
• Enable the virtual printer
• Enable audio output
• Enable incoming audio

Assigning a User Group with Impersonification

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

The impersonation value can come from different sources:

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

Priority rules:

• There can be multiple impersonations linked to groups (from MFA), but only one for each group (it takes priority over the global one).
• There can be only one AD impersonation (it takes priority over the global one).
• There can be only one global impersonation (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 impersonation value is present (the group value is used if Group::Impersonification exists, otherwise the global or AD value 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 impersonation value (the group value if Group::Impersonification exists, otherwise the global or AD value if ImpersonificationGlobal/ImpersonificationAD exists) exactly matches one of the OS Login/AD Login entries listed in the group configuration.

User Group assignment summary table

User Group assignment summary table with impersonification set to true

OS Login/AD Login/Ssh PKey Login assignment to a User Group

Once a User Group has been assigned to a Host, you can assign it predefined users, who must exist on the host itself (OS Login and/or Ssh PKey Login) or in an Active Directory domain (AD Login).

All three, once populated, contribute to the creation of the OSA Vaults; respectively:

• OS Login Vault for local machine users
• Ssh PKey Vault for local machine users with access via SSH key
• AD Login Vault for domain users

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

Here you can enter as many users as you want to allow that specific User Group to log in with.

To enable access via Ssh PKey, the prerequisites are:

• entering the Private Key in the corresponding Vault, as explained in the following paragraphs, so that the Ssh Key Name is available in the drop-down menu;
• entering the Public Key on the machine, as explained in the following paragraphs.

If you also want to store the password, so that the user does not have to remember, 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 in 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 whose passwords you want to enter, and enter 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 in 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.

Ssh Private Key Entry for a Ssh PKey Login (Ssh PKey Vault)

To enter a Ssh Private Key in the Vault (assigned to a User Group) of a Host, you must go to the Ssh PKey Vault section via the menu PAM Management > Vault Manager > Ssh PKey Vault.

Search for the corresponding resource in the search bar and click the green key button to edit the SSH PKeys.

From here it is possible to enter the Ssh Private Key and the optional passphrase:

Remember to always perform Save and Re‑Init.

Adding the Public Key to the machine

For access via Ssh PKey Login to succeed, in addition to uploading the Private Key to the corresponding Vault, the matching Public Key must be present on the target machine, associated with the user you want to log in as.

Linux

On most Linux distributions, the public key must be added to the ~/.ssh/authorized_keys file of the relevant user:

mkdir -p ~/.ssh
echo "<public-key-content>" >> ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Make sure the owner of the .ssh directory and of the authorized_keys file is the user itself, and that the server’s SSH service is configured to accept public key authentication (PubkeyAuthentication yes parameter in the /etc/ssh/sshd_config file).

Windows

On Windows, the OpenSSH Server component must be installed and enabled. To check whether it is present, open PowerShell as administrator and run:

Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH.Server*'

If the State field shows Installed, the component is present; otherwise it can be installed with:

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

Also verify that the sshd service is running and set to start automatically:

Get-Service sshd
Set-Service -Name sshd -StartupType Automatic
Start-Service sshd

With the OpenSSH server enabled, the path of the authorized_keys file depends on the user type:

• for a standard user, the key must be added to the C:\Users\<user>\.ssh\authorized_keys file;
• for an administrator user, the key must be added to the C:\ProgramData\ssh\administrators_authorized_keys file.

In the latter case, the file’s permissions (ACLs) must also be set correctly, so that only the SYSTEM user and the Administrators group can access it, for example via PowerShell:

icacls.exe "C:\ProgramData\ssh\administrators_authorized_keys" /inheritance:r /grant "Administrators:F" /grant "SYSTEM:F"

After entering the key, verify that the configuration file C:\ProgramData\ssh\sshd_config contains (and does not have commented out) the parameter:

PubkeyAuthentication yes

If the file is modified, the service must be restarted for the changes to take effect:

Restart-Service sshd

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 October 1 at 08:00 to October 5 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.

How users see the metrics (quality preview and interactive graph) is described in the Oplon Secure Access user guide.

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 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, behavior 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 clicking 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 behavior 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 replace 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 for RDP access, 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 perform Save and Re‑Init at the end.