4.7.1.6. Administration
The administration section focuses on advanced tasks related to the ongoing management and maintenance of the system covering more complex configurations and advanced features.
We will detail the steps to configure the system, preparing it to operate its 2SRA functionality.
Note
It is essential to have correctly deployed and configured the necessary nodes for this use case.
In this section, you will find the following content:
Network Device Configuration:
Authentication Configurations:
SAML authentications:
Agent Configuration:
2SRA Policies:
OTP Configurations:
Network Device Configuration
4.7.1.6.1. Set Firewall as a Network Device
It is necessary to configure the Firewall as a Network Device in the ON Core CMDB. To do this, navigate to ON CMDB > Network Devices and click Add new:

The minimum required information to configure the Firewall as a Network Device is as follows:
General

IP: The IP address that identifies the device (Firewall IP).
Hostname: The hostname that identifies the device (Firewall hostname).
Brand / Model: The brand and model of the device.
Disconnection Settings - WireGuard VPN
WireGuard VPN allows TogglePort connections for re-authentication. To enable this, configure the disconnection settings with the following information:

In the Disconnection type field, select the “API Rest” type.
Scroll down to the API Rest Properties:

In this section, define the following parameters:
API Rest protocol: The connection protocol to the Firewall’s API Rest (default: HTTPS).
API Rest port: The connection port for the Firewall’s API Rest (default: 10443).
API Key: The API key required to make requests to the Firewall’s API Rest.
To obtain an API key from the VPN Gateway, navigate to ON CMDB > Security > API Key in the Administration Portal.

Click the Add new button:

If you have multiple OpenNAC nodes (workers), enable the Enable API Key for Any Source IP option. Otherwise, enter the VPN Gateway IP in the IP field.
Authentication Configurations
4.7.1.6.2. Defining User Data Sources
By defining multiple User Data Sources (UDS) on a system, different authorities can be used in the authorization process. Active Directory attributes support this process.
To create a new UDS, follow the steps provided below:
Navigate to ON CMDB > User data sources.
Click the Add new button.
Define a name and select a type for the new UDS. In our example we will select the Active Directory type. It displays the following configuration properties:

Parameter |
Description |
---|---|
Name |
The name used by the UDS. In this case, this is a UDS type LDAP/AD, and for this reason, for instance: AD Mycompany |
Type |
Defined as LDAP/AD. The database connection could be used to get user attributes. |
Read only |
If the query is launched with a Read only flag. This will avoid any write action in the commands. |
Enabled |
The UDS can be enabled and disabled. |
Host |
The LDAP/AD IP where the queries are launched. For instance: 172.16.11.5, additional IPs can be added. |
Port |
The port used for the AD/LDAP Search query, by default, uses an unsecured connection. The default is 389 and if AD/LDAP SSL is enabled is 636. |
Username |
The user registered in the AD/LDAP server. This allows us to bind and use AD/LDAP information. For instance, the user created the picture in the active directory in Step 1. |
Password |
The password for the AD/LDAP binding. |
Base DN |
BaseDN at the top of the domain name structure. Our domain is named mycompay.local and its BaseDN is DC=mycompany,DC=local. |
AccountDomainName |
The DNS name for the domain is in uppercase. In this case MYCOMPANY.LOCAL. |
AccountDomainName Short |
The short name for the domain or commonly named NETBIOS name. For instance, MYCOMPANY. |
AccountFilterFormat |
The attribute used to select users. We have included two options, but**only one must be used**. In this example sAMAccountName=%s is defined for Active Directory, and uid=%s for LDAP Servers. |
Bindrequires DN |
It is basically the credential you are using to authenticate against an LDAP. When using a bindDN, it usually comes with a password associated with it. Sometimes, anonymous binding doesn’t allow certain types of actions. |
Uid attr |
The attribute is used to identify users’ IDs. The filter changes depending on if AD or LDAP is used. |
Mail attr |
The filter is used to identify the mail as an attribute of the user. |
Phone attr |
The filter is used to identify the phone number as an attribute of the user. |
Group attr |
The filter use to identify the groups as an attribute of the user. |
Enable LDAPS |
For authenticating and authorizing users where LDAP communication is transmitted over an SSL tunnel port 636 TCP. |
Enable TLS |
For securing communication between LDAP clients and LDAP servers. |
Allow nested groups on AD group authorizations |
* Flag that controls whether subgroup memberships within AD groups are considered for access permissions |
Once finished with this configuration window, click Accept. It should now be displayed in the User data sources table.
Check the Last status column. If it shows Ready, the configuration is done. If not, right-click on it and it will display the following options:

Select the Check status option, and if there are no errors, the UDS will change its state to Ready.

- Otherwise:
Select it
Click on the Check status button.
If there are no errors, the UDS will change state to “ready”.
4.7.1.6.3. Creating LDAP filters
This section explains how to generate LDAP filters. Filters are used to segment groups of users accessing the network. These filters can be later applied in access policies.
Note that this document provides an example, you must create LDAP filters required for your access policies.
1. Navigate to ON CMDB > LDAP/AD Filters and click on the Add new button.

2. Assign a name to the filter and a apply a query. Follow the instructions described in the LDAP filter section to get the attributes needed to this query.

3. Click on Accept to save the configurations and you will see the filter disabled in the main table.
4. To enable the new filter, select it and click the Check & Enable LDAP/AD Query button.

5. Choose the active directory to associate this filter with and click on Accept:

6. In case no errors occur, the filter will be enabled.

SAML authentications
4.7.1.6.4. SSO Authentication Flow with SAML for VPNs
You can perform a Single Sign-On (SOO) authentication flow using SAML to perform WireGuard-type VPN authentications.
To configure this authentication, execute the following steps:
4.7.1.6.4.1. Creating a Captive VPN Workflow
When users start the authentication process, they will be redirected to the system’s Captive Portal and must follow the flow you have configured for SAML authentications.
Note
This step consists on setting up the connection between the Service Provider (SP) and the Identity Provider (IdP). You will need the IdP federation metadata and the IdP server ID to create this workflow.
Once you have this data, follow the steps described in the ON Captive > Captive VPN workflows section.
4.7.1.6.4.2. Federation of the SP in the IdP
After creating the Captive VPN Workflow, you can retrieve the metadata and identity of your Service Provider (SP) at the following link:
https://<captive_portal_ip_or_domain>/simplesaml/module.php/saml/sp/metadata.php/saml-test?output=xhtml

This metadata must be provided to the IdP to complete the federation between the SP and IdP.
4.7.1.6.4.3. Creating Captive Instances
Once you have defined the Captive VPN Workflow, you will need to add it to a Captive Portal instance.
A Captive Instance is a customized deployment of the Captive Portal, designed to control user authentication and access for a specific network or user group. From this section you will associate workflows and themes to an instance.
Navigate to ON Captive > Captive instances to create a new instance:

To create a new Captive instance, click on the Add new button.
The following configurations must be completed to create a functional Captive Instance, based on the settings described in the previous sections:
General

Name: The name of the new captive instance being created.
Captive node IP: The IP address for the Captive node. This field is required.
Portal IP/Domain: The IP address or FQDN of the server running the OpenNAC Enterprise Captive Portal. It can be the same IP of the ON Core server if the captive portal will be running on this server along with ON Core, or the address can be that of a standalone server dedicated to running the OpenNAC Enterprise captive portal. This field is required.
Installed in core: Set to yes if the Captive Portal is running on the ON Core. Automatically, the Captive node IP will be set to localhost.
Description: A meaningful description of this new Captive instance.
Enable language selector: Enables the language selector in the Captive portal instance. The shown languages depend on the languages configured inside ON Captive -> Captive themes in the General section, with the corresponding translations in the Translations section. If this selector is not enabled, the language will be the browser language.
List of IPs that will be redirected to the default page: The IP or IPs that will be redirected.

Workflows

Select from the listed Workflows, or create a new one to associate with this instance.
VPN Workflows

Select one of the listed VPN Workflows, or create a new one to associate with this instance.
Theme

Select one of the listed Themes, or create a new one to associate with this instance.
Click on Accept to save the configurations.
4.7.1.6.4.4. Configuring the Agent for SAML Authentication
To use SAML for authenticating VPN connections with the WireGuard service, additional configuration is required. This functionality must be enabled in the ON Agent application.
To activate SAML authentication for the agents, navigate to ON Agent > Agent Profiles, and in the relevant profile (default profile is used by default), enable the following options: Enable WireGuard and Authenticate WireGuard using SAML.

4.7.1.6.4.4.1. SAML Authentication Flow Example
Once you have already downloaded and installed the Agent:
Right-click on the Agent icon in the taskbar and select the “Connect VPN with WireGuard”:

It will open the Agent UI, and it will attempt to connect to the VPN automatically without requiring access credentials. To establish the connection, click on Connect.

A new window will automatically open in the browser, directing you to the IdP access page (example image), where you need to enter our credentials.

Once you are logged in, the Agent will receive information to establish the VPN connection:

The Agent will automatically configure itself and access the VPN:

Agent Configurations
4.7.1.6.5. Configuring Agent Profiles
Agent Profiles define the settings that are sent to Agents installed on client devices, based on the information received from them.
You need to add the connection profile to the Agent profile configuration, which is registered as the default profile. This ensures that when the Agent connects with the backend, the VPN configuration is sent.
Navigate to ON Agent > Agent Profiles:
Select the “default” profile and click on Edit.
Scroll down to the Taskbar Configuration section and enable “Enable UI”, “Enable the client authentication option” and “Enable WireGuard”.

Once you have selected the desired settings, click on Accept to save your changes.
4.7.1.6.6. Download and Install Agent Options
After configuring the Agent Profile, you need to set up the Agent download to specify the connection IP and enable the WireGuard VPN service.
Navigate to ON Agent > Agent configuration > Download & parse, and under Download & Install agent options select a server rom the Server list:
Note
In the Server list field, you can configure multiple Agent URLs and set one as the default. This is where the Agent can be downloaded from. You can specify the URL as an IP address, IP:PORT, or FQDN. This is where the Soluble Agent will send its payloads.
Click Save to save the settings.
2SRA Policies
4.7.1.6.7. Tag Policy Profiling
You can create tags for user validation policies to group characteristics of remote devices collected through the Agent. This allows for more granular device profiling, which can be used for access control.
Navigate to ON NAC > Tag policies > UD tag policies section and click the Add new button:

A configuration window will appear:

Here are the key fields to configure:
Name: The name of the tag policy.
- Tag: The tag to apply. In this case, the tag used is EPC_SECURITY_COMPLIANCE.
The conditions for this tag to be created (RegEx-based). In this case: (&,’ISS_AV_UPDATE’,’ISS_AV_ENABLED’,’ISS_FW_ENABLED’)
Search Tag Assistant: Assists in finding tags used in the rule.
Comment: A comment or description of the policy.
Enabled: Enables the rule for use upon creation.
Later, when configuring access policies, you can use the tags defined here as preconditions. This allows you to restrict connections to users whose devices meet the criteria associated with the tag.
4.7.1.6.8. Configuring Policies
Note
Before configuring policies, ensure that the wireGuardSync plugin is set up. Once completed, the plugin will be available for policy configuration.
Navigate to Configuration > Plugins and click Edit plugin for wireGuardSync.

After configuring the plugin parameters and enabling its flag, it will be available in Policies Postconditions.
To associate the WireGuard plugin to a policy:
Navigate to the ON NAC > Policies section.
Scroll down to the Postconditions configuration of the policy you want to associate the WireGuard plugin and select the WireGuard plugin:

Now that the WireGuard plugin is configured, you can proceed to set up VPN user validation policies. Below are examples of four policies you can create: one for Admin users, one for Standard users, one for Rejected users, and one for Visibility Agent.
4.7.1.6.8.1. Creating an Admin Users Policy
Navigate to ON NAC > Policies and click the Add new button.

In the General section:
Name: Enter the policy name.
Enable: Set to Yes to enable the policy.
Section: Specify the policy section.
Comment: Add any relevant comments about the policy.

In the Preconditions: Users form:
Click on Set User Data Source.
Select the Active Directory to be used.
Click on Set LDAP Filter.
Choose the appropriate rule. If it doesn’t exist, you can create a new one.

In the Preconditions: User Devices configuration, add a tag from the list of tags you previously created.

In the Preconditions: Sources configuration, select only VPN:

In the Postconditions section:
Click on Set VLAN.
Select the VLAN named “Switch default”.

Zone Assignment: In the form in Postconditions: Custom params
Click on Add new
Fill in the following fields:
Type: Free text
Name: VPNGW-Role
Value: Enter the name of the dynamic zone you previously created, which will associate the AD user group, selected LDAP filter, and the rule you are creating. This allows the automatic assignment of ACL security policies in the final stage.
Click on Accept to save the configurations.
4.7.1.6.8.2. Creating a Standard User policy
Repeat the steps 1.
In the General section:
Name: Enter the policy name.
Enable: Set to Yes to enable the policy.
Section: Specify the policy section.
Comment: Add any relevant comments about the policy.

Select the necessary LDAP Filter in the Preconditions: Users configuration. For this example, use the following filter:

Repeat the steps 4,5,6.
create a parameter with a new value in the Postconditions: Custom Params configuration. This parameter will be used in the firewall to distinguish VPN networks. The corresponding zone must be assigned here:

Click on Accept to save the configurations.
4.7.1.6.8.3. Creating a Reject User policy
A Reject policy must be created to deny the connection of users who do not comply with the other VPN policies. This policy should be placed at the end of all VPN policies.
Repeat the steps 1.
In the General section:
Name: Enter the policy name.
Enable: Set to Yes to enable the policy.
Section: Specify the policy section.
Comment: Add any relevant comments about the policy.

In Preconditions: Sources, select only VPN:

In Postconditions:
Click on Set VLAN
Select the VLAN “Access Denied”

Click on Accept to save the configurations.
4.7.1.6.8.4. Creating a Visibility Agent policy
This policy will assign an Agent profile to all devices with the Agent installed before they connect.
In the General section:
Name: Enter the policy name.
Enable: Set to Yes to enable the policy.
Section: Specify the policy section.
Comment: Add any relevant comments about the policy.

In Preconditions: User Devices:
Add the Agent tag as filter within the “Tags of User Device” field ($,’ONC_AGENT’).
Check the expression is correct by clicking Check expression.

In Preconditions: Sources, enable the Visibility flag:

In Postconditions:
Click on Set VLAN
Select the VLAN “Switch default”

In Postconditions:
Select the previously configured Agent Profile. In this case, “default”.

One-Time Password
4.7.1.6.9. OTP Configuration
4.7.1.6.9.1. OTP Email Template
This section explains how to configure the email that will be sent to users with their One-Time Password.
Navigate to the OTP configuration tab in the Configuration > OTP section and configure the email options:
One time QR: If we enable one time QR mode, the QR will adopt the following parameters:
TTL one time QR (in minutes): Defines the time in minutes that it will take for a QR image to expire from when it is sent until it is scanned by the user. By default 480 minutes.
Maximum number of uses of QR image: Set the maximum number of scans of the same QR image.
Captive portal URL: Address for the unique QR.

E-mail configuration
Email settings without one-time QR mode enabled.
Email from: Enter the e-mail address of the sender.
Username of ‘E-mail from’: Provide a descriptive name (e.g., the sender’s name or the organization’s name) instead of an email address, especially avoiding the same email address used in the “Email from:” field. This information is crucial to prevent potential rejection by mail relay servers due to anti-spam rules.
E-mail title: Enter subject of the email.
Email QR template: This section includes the HTML code that will be seen in the content of the email sent with the one time QR off mode.

One time QR e-mail configuration
Email settings without the one-time QR mode enabled.
Email from: Enter the e-mail address of the sender.
Username of ‘E-mail from’: Provide a descriptive name (e.g., the sender’s name or the organization’s name) instead of an email address, especially avoiding the same email address used in the “Email from:” field. This information is crucial to prevent potential rejection by mail relay servers due to anti-spam rules.
E-mail title: Enter subject of the email.
Email QR template: This section includes the content that will be seen in the the email sent with the one time QR off mode.
Click on Save to apply the changes.
4.7.1.6.9.2. OTP General Configuration
Besides the email configuration, from the OTP Configuration tab, you can also set the general specifications for the OTP service:

General
OTP Service name: Identification name for the OTP service.
Enable “Send OTP secret as QR”: Select “yes” so that the user will receive a QR code that they will use in Google Authenticator.
Allow to send QR more than once: By default, the QR Code can be sent only once (if you want to send another email you have to generate a new OTP secret). In case you want to reuse the same code, enable this field.
One time QR: If we enable one time QR mode, the QR will adopt the following parameters:
TTL one time QR (in minutes): Defines the time in minutes that it will take for a QR image to expire from when it is sent until it is scanned by the user. By default 480 minutes.
Maximum number of uses of QR image: Set the maximum number of scans of the same QR image.
Captive portal URL: Address for the unique QR.
4.7.1.6.9.3. Sending QR Codes via Email
All OTP related tasks are in the Configuration > OTP section. Switch tabs to find different types of OTP user configurations:
Admin Users
Local Users
External Users

Add new users through the Admin Users or Local Users tabs by clicking the Add new button and entering the desired username for the QR owner:

You can also regenerate QR codes for selected users.
To add new users through the OTP Eternal Users tab, click the Add new button and enter the the desired username for the QR owner and select its User data source:

You can create a OTP for a user by selecting a group from an LDAP or AD by clicking on Create OTP using LDAP/AD group:

User data source: The LDAP or AD source we want to use.
Users group: The group of users that will be using the OTP.
Regenerate OTPs that already exist and send QR: Flag that allows to enable or disable the OTP regeneration if it already existed.
After creating a user or group OTP and sending the QR code, users can scan it with any authenticator app, such as Google Authenticator, which will generate a dynamic PIN for about 30 seconds.

Users can then connect to the VPN by selecting 2FA in the authentication window, entering their username, password, and OTP PIN.

4.7.1.6.9.4. OTP Policies
From the OTP Policies tab, you can configure policies that must be met for users to request OTPs during authentication.

By clicking on Add new, you create create new policies:

General
Name: Name of the new OTP policy.
Description: Description of the new policy for ease of identification.
Frequency: Frequency with which the OTP will be requested during a user’s authentication: always, hourly, every 2 hours, every 3 hours, every 4 hours, every 6 hours, every 8 hours, every 12 hours, daily, weekly, monthly, quarterly.
Enabled: Flag to enable the policy.
All tag rules must be met to accept the policy: If not enabled, only a single rule must be met to apply the policy.
Precondition: Tag rules
Click on Add new o add a new tag rule by configuring:

Rule name: Tag rule name.
Expression: Tag or tag substring marked with an asterisk. Examples: EPT_DESKTOP_WINDOWS, EPT_DESKTOP_*, EPT_*_WINDOWS, *_WINDOWS.
Precondition: Source IPs and networks
Click on Add new to add a source IP or network for the precondition:

4.7.1.6.9.4.1. OTP Policy Evaluation
Once the policy is created, if you want to check the policy evaluation, execute the following steps:
Connect to VPN using the Agent.
Enable the Verbose mode flag in Configuration > Configuration vars > Logs.
See the OTP policy evaluation by inspecting the opennac-api.log:
/var/log/opennac/opennac-api.log
If the user connects to the VPN and no OTP policy matches, the Default policy will be evaluated. If there is no condition configured, the user will always need to introduce the OTP code (Policy frequency applied: CHECK OTP).
Mar 21 13:05:45 onprincipal opennac-api[1209487]: 2024-03-21 13:05:45 DEBUG: [2c4e] [OtpPolicyMapper][user1][testa] Checking OTP policy...
Mar 21 13:05:45 onprincipal opennac-api[1209487]: 2024-03-21 13:05:45 DEBUG: [2c4e] [OtpPolicyMapper][user1][testa] OTP Policy tag rule NOT fullfilled: EPT_*_WINDOWS
Mar 21 13:05:45 onprincipal opennac-api[1209487]: 2024-03-21 13:05:45 DEBUG: [2c4e] [OtpPolicyMapper][user1][testa] OTP Policy tag rule fullfilled: ONC_AGENT
Mar 21 13:05:45 onprincipal opennac-api[1209487]: 2024-03-21 13:05:45 DEBUG: [2c4e] [OtpPolicyMapper][user1][testa] OTP Policy preconditions NOT fullfilled
Mar 21 13:05:45 onprincipal opennac-api[1209487]: 2024-03-21 13:05:45 DEBUG: [2c4e] [OtpPolicyMapper][user1][DEFAULT] Checking OTP policy...
Mar 21 13:05:45 onprincipal opennac-api[1209487]: 2024-03-21 13:05:45 DEBUG: [2c4e] [OtpPolicyMapper][user1][DEFAULT] OTP Policy tag rule NOT fullfilled: EPT_DESKTOP_WINDOWS
Mar 21 13:05:45 onprincipal opennac-api[1209487]: 2024-03-21 13:05:45 DEBUG: [2c4e] [OtpPolicyMapper][user1][DEFAULT] OTP Policy preconditions NOT fullfilled
Mar 21 13:05:45 onprincipal opennac-api[1209487]: 2024-03-21 13:05:45 DEBUG: [2c4e] [OtpPolicyMapper][user1][DEFAULT] OTP Policy frecuency applied: CHECK OTP
If the user connects for the first time and matches with a policy, this policy will evaluate the user device tags (either the last payload tags added or the ones obtained through tag rules, user device profiling, etc.).
At this point, the user will be prompted to enter the OTP (Policy frequency applied: CHECK OTP).
Mar 21 13:19:36 onprincipal opennac-api[1208860]: 2024-03-21 13:19:36 DEBUG: [3958] [OtpPolicyMapper][user1] Evaluating OTP policies...
Mar 21 13:19:36 onprincipal opennac-api[1208860]: 2024-03-21 13:19:36 DEBUG: [3958] [OtpPolicyMapper][user1][2hour] Checking OTP policy...
Mar 21 13:19:36 onprincipal opennac-api[1208860]: 2024-03-21 13:19:36 DEBUG: [3958] [OtpPolicyMapper][user1][2hour] OTP Policy tag rule NOT fullfilled: *_COMPLIANCE
Mar 21 13:19:36 onprincipal opennac-api[1208860]: 2024-03-21 13:19:36 DEBUG: [3958] [OtpPolicyMapper][user1][2hour] OTP Policy preconditions NOT fullfilled
Mar 21 13:19:36 onprincipal opennac-api[1208860]: 2024-03-21 13:19:36 DEBUG: [3958] [OtpPolicyMapper][user1][testa] Checking OTP policy...
Mar 21 13:19:36 onprincipal opennac-api[1208860]: 2024-03-21 13:19:36 DEBUG: [3958] [OtpPolicyMapper][user1][testa] OTP Policy tag rule NOT fullfilled: EPT_*_WINDOWS
Mar 21 13:19:36 onprincipal opennac-api[1208860]: 2024-03-21 13:19:36 DEBUG: [3958] [OtpPolicyMapper][user1][testa] OTP Policy tag rules precondition fullfilled.
Mar 21 13:19:36 onprincipal opennac-api[1208860]: 2024-03-21 13:19:36 DEBUG: [3958] [OtpPolicyMapper][user1][testa] OTP Policy frecuency applied: CHECK OTP
Mar 21 13:19:43 onprincipal opennac-api[1208861]: 2024-03-21 13:19:43 DEBUG: [a62f] [OtpPolicyMapper][user1] Evaluating OTP policies...
Mar 21 13:19:43 onprincipal opennac-api[1208861]: 2024-03-21 13:19:43 DEBUG: [a62f] [OtpPolicyMapper][user1][2hour] Checking OTP policy...
Mar 21 13:19:43 onprincipal opennac-api[1208861]: 2024-03-21 13:19:43 DEBUG: [a62f] [OtpPolicyMapper][user1][2hour] OTP Policy tag rule NOT fullfilled: *_COMPLIANCE
Mar 21 13:19:43 onprincipal opennac-api[1208861]: 2024-03-21 13:19:43 DEBUG: [a62f] [OtpPolicyMapper][user1][2hour] OTP Policy preconditions NOT fullfilled
Mar 21 13:19:43 onprincipal opennac-api[1208861]: 2024-03-21 13:19:43 DEBUG: [a62f] [OtpPolicyMapper][user1][testa] Checking OTP policy...
Mar 21 13:19:43 onprincipal opennac-api[1208861]: 2024-03-21 13:19:43 DEBUG: [a62f] [OtpPolicyMapper][user1][testa] OTP Policy tag rule NOT fullfilled: EPT_*_WINDOWS
Mar 21 13:19:43 onprincipal opennac-api[1208861]: 2024-03-21 13:19:43 DEBUG: [a62f] [OtpPolicyMapper][user1][testa] OTP Policy tag rules precondition fullfilled.
Mar 21 13:19:43 onprincipal opennac-api[1208861]: 2024-03-21 13:19:43 DEBUG: [a62f] [OtpPolicyMapper][user1][testa] OTP Policy frecuency applied: CHECK OTP
If the user have previously matched an OTP policy, the next time they connect to the VPN, the policies will match again. It will indicate that the OTP is not necessary until the frequency time determines that OTP usage is required again. (Policy frequency applied: IGNORE OTP).
Mar 21 13:25:29 onprincipal opennac-api[1208864]: 2024-03-21 13:25:29 DEBUG: [baef] [OtpPolicyMapper][user1] Evaluating OTP policies...
Mar 21 13:25:29 onprincipal opennac-api[1208864]: 2024-03-21 13:25:29 DEBUG: [baef] [OtpPolicyMapper][user1][2hour] Checking OTP policy...
Mar 21 13:25:29 onprincipal opennac-api[1208864]: 2024-03-21 13:25:29 DEBUG: [baef] [OtpPolicyMapper][user1][2hour] OTP Policy tag rule NOT fullfilled: *_COMPLIANCE
Mar 21 13:25:29 onprincipal opennac-api[1208864]: 2024-03-21 13:25:29 DEBUG: [baef] [OtpPolicyMapper][user1][2hour] OTP Policy preconditions NOT fullfilled
Mar 21 13:25:29 onprincipal opennac-api[1208864]: 2024-03-21 13:25:29 DEBUG: [baef] [OtpPolicyMapper][user1][testa] Checking OTP policy...
Mar 21 13:25:29 onprincipal opennac-api[1208864]: 2024-03-21 13:25:29 DEBUG: [baef] [OtpPolicyMapper][user1][testa] OTP Policy tag rule NOT fullfilled: EPT_*_WINDOWS
Mar 21 13:25:29 onprincipal opennac-api[1208864]: 2024-03-21 13:25:29 DEBUG: [baef] [OtpPolicyMapper][user1][testa] OTP Policy tag rules precondition fullfilled.
Mar 21 13:25:29 onprincipal opennac-api[1208864]: 2024-03-21 13:25:29 DEBUG: [baef] [OtpPolicyMapper][user1][testa] OTP Policy frecuency applied: IGNORE OTP
4.7.1.6.10. Agent 2SRA End User Guide
Once the Agent is installed on client computers (downloaded from the Administration Portal), you can proceed with the registration in Google Authenticator and run connection tests.
For more details on installing the Agent, refer to the Node Deployment Guide.
4.7.1.6.10.1. Registering 2FA with Google Authenticator
When establishing a VPN connection, two-factor authentication (2FA) will be required. The second factor is provided through Google Authenticator, which you set up by scanning a QR code sent to you via email.
Installing Google Authenticator
To get started, download the Google Authenticator app from one of the following links:
App Store:
https://apps.apple.com/us/app/google-authenticator/id388497605
PlayStore:
https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2
Once installed, scan the QR code sent to your email. The email will look similar to this:

Setting Up 2FA in Google Authenticator
If this is your first time using Google Authenticator, follow these steps to complete the 2FA registration:
Click “START SETUP”
Then click on “Scan Barcode”
Scan the QR code that is attached to the email
Now you can view the code
If you have previously used Google Authenticator, follow these steps to complete the 2FA registration:
Click on the “+” symbol at the top right
Then click on “Scan Barcode”
Scan the QR code that is attached to the email
Now you can view the code
Here is an example of how the OTP code appears in Google Authenticator:

4.7.1.6.10.1.1. Registering One-Time QR Codes
When connecting to the VPN, you will also need to register a one-time QR code provided through a Captive Portal (as configured). The QR code is sent to you via email.
To obtain the 2FA code, scan the QR code received in your email, which will look like this:

By scanning the code, you will be directed to a web portal that will generate the OTP and redirect you to your password wallet (Apple) or default application (Android) to save and display the access code:

In the event that the QR has expired or the maximum number of scans has been exceeded, the portal will display an error message.