4.5.5. 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 BYOD functionality.
Note
It is essential to have correctly deployed and configured the necessary nodes for this use case.
This section provides a step-by-step guide for creating and customizing a captive workflow, detailing the necessary policies for successful implementation. Here, you will find the following content:
Integration and Network Device Management:
Authentication Configurations:
Captive Configurations:
BYOD Policies
Integration and Network Device Management
4.5.5.1. Join ON Core to Active Directory domain
We recommend registering the ON Core server in the domain. If no domain is available, you can skip to the next step.
To complete this process, the user must have specific permissions to join the Active Directory (AD). Afterward, the user account can be modified to one with read-only permissions for user queries.
For more information on joining a domain, refer to the Administration Portal section: Join Domain Wizard
4.5.5.2. Registering Network Devices in the CMDB
The CMDB is the ON Core database. It stores, in an organized manner, all known data associated with each connection made on the network. This database contains information related to systems, infrastructure, networks, VLANs, security profiles, user devices, network devices, and more.
In this section of UNAC, we are primarily interested in network devices, such as switches, APs, AP controllers, etc.
Registering network devices in the CMDB allows you to customize the characteristics of each device so that the system can interact with them appropriately.
Note
If you want to register a predefined group of devices, refer to Bulk import of devices.
To register a new network device, navigate to the ON CMDB > Network Devices:
Note
If you do not perform any configurations, the default configuration defined in Configuration > Configuration Vars > NetDev will be used. The parameters in this section are the same as those available when configuring any of the devices.
Click on Add new to register a new device. The minimum required information that you must provide is outlined below.
General
The minimum fields required to configure within this tab are: IP, Hostname, and Brand/Model.
IP: IP address that identifies the device (used solely for identification in the device table).
Hostname: Hostname that identifies the device.
Brand / Model: Brand and model of the device.
Note
It is important to correctly define the brand and model since these will be used to determine the behavior of the system in terms of communication with these devices.
Disconnection settings
In the Disconnection settings tab, the configuration of the Toggle Port functionality is defined. This functionality allows you to force a disconnect from an authenticated session. For example, this allows you to carry out a re-evaluation of the policies in case they have been modified and apply VLANs, ACLs, etc., to the session.
There are two methods of session disconnection:
CoA (Change of Authorization): CoA is a RADIUS mechanism that disconnects a specific session without the need to modify the port status (enable/disable) of the network device.
SNMP: Using SNMP, the interface where the device has been authenticated is disabled and then enabled. This causes the device to re-authenticate and subsequently evaluate policies on the system.
Although both methods perform the same function and are equally valid, the use of SNMP is recommended.
Disconnect type:
Use default option: The configuration defined in Configuration > Configuration Vars > NetDev will be applied.
CoA: Use of CoA to perform session disconnections.
SNMP: Use of SNMP to perform session disconnections.
SNMPProperties
SNMP version: Version used for SNMP messages. The required attributes for each of the versions are:
V1 (not recommended):
SNMP RO: SNMP community with read permissions.
SNMP RW: SNMP community with write permissions.
V2c:
SNMP RO: SNMP community with read permissions.
SNMP RW: SNMP community with write permissions.
V3 (recommended):
SNMP v3 Security name: SNMP username.
SNMP v3 Security level: Security level (noAuthNoPriv/authNoPriv/authPriv).
Depending on the selection, it will be necessary or not to configure some of the following attributes.
SNMP v3 Authorization protocol: Authorization protocol (MD5/SHA).
SNMP v3 Authorization pass phrase: Password for authorization.
SNMP v3 Privacy protocol: Privacy protocol (DES/AES).
SNMP v3 Privacy pass phrase: Password for privacy.
CoAProperties
CoA password: Password defined in the network device to authenticate CoA requests.
CoA port: Port used for communication. (Usually 3799).
After completing all the necessary information, click on the Accept button to save the configured network device.
For bulk-importing devices, refer to the UNAC use case section.
4.5.5.3. Managing APs and Controllers in the CMDB
When there are multiple APs centrally controlled by a controller in the network, the controller must be added as a network device in the CMDB.
Additionally, for each AP in the CMDB, besides the minimum information detailed above, it is essential to include IP management information:
This IP must correspond to the IP of the controller that manages the AP.
Authentication Configuration
4.5.5.4. Defining User Data Sources
User Data Sources (UDS) are the system’s sources for user authentication. These may also be used in the process of authorizing or evaluating system policies.
There are different types of UDS, such as databases or AD/LDAP.
By default, there is a UDS called “LocalDB”. This is the system’s local database for storing local users. While useful for testing, it is not recommended for use in production.
To view the existing UDS, navigate to ON CMDB > User Data Sources. To add a new UDS, click on the Add new button.
A new window will open, which will have a specific format depending on the type of UDS you want to create. The topics below will detail how to create both the Database type and the LDAP/AD type.
Database
The configuration parameters for a UDS of type “Database” are:
Name: Name to be assigned to the UDS.
Type: Type of UDS (Database, LDAP or AD).
Read only: Check to define if said UDS is read-only .
Enabled: Check to enable or disable udS.
Table: Table Of the database to be queried.
Identity column: A column in the database table that contains the user ID.
Credential column: Column of the database table that contains the user’s credentials.
User name column: Column of the table that contains the user’s name.
User e-mail column: Column of the table that contains the user’s e-mail.
User telephone column: Column of the table that contains the user’s phone.
Additional condition query: Query conditions additional to the database.
Adapter: Type of database adapter (MySQL, PostgrSQL, Oracle…)
DDBB Charset: Character set used by the database (e.g. utf8)
DDBB Host: Name of the host or address of the database to read.
DDBB Write Host: If you want to write to the database, the host name or address.
DDBB Name: Name of the database.
DDBB Username: Username for database access.
DDBB Password: The user’s password for accessing the database.
LDAP/AD UDS
The configuration parameters for a UDS of type “LDAP/AD” are:
Name: Name that will be assigned to the UDS.
Type: Type of UDS (Database, LDAP or AD).
Read only: Check to define if said UDS is read-only .
Enabled: Check to enable or disable udS.
LDAP Host: The LDAP/AD IP where queries are launched.
LDAP Port: The port used for the AD/LDAP search query.
LDAP Username: This is the user registered on the AD/LDAP server, which must have read permissions on the server. It is recommended that such a user only have read permissions.
LDAP Password: This is the password for the AD/LDAP binding.
LDAP Base DN: BaseDN at the top of the domain name structure. For example, if our domain is mycompany.local, its BaseDN is DC = mycompany, DC = local.
LDAP AccountDomainName: This is the DNS name of the domain in uppercase.
LDAP AccountDomainName: Short Is the short domain name or NETBIOS name commonly called, for example, MYCOMPANY.
LDAP AccountFilterFormat: This is the attribute used to select users. Two options have been included (only one should be used). It is used (sAMAccountName =% s) for Active Directory and (uid =% s) for LDAP servers.
LDAP Bindrequires DN: The bindDN DN is the credential you are using to authenticate against an LDAP. When using a bindDN, it usually comes with an associated password, sometimes the anonymous link does not allow certain types of actions.
LDAP Uid attr: This is the attribute used to identify user IDs, depending on whether AD or LDAP is used for filter change.
LDAP Mail attr: This is the filter used to identify mail as a user attribute.
LDAP Phone attr: It is the filter that is used to identify the phone number as an attribute of the user.
LDAP Group attr: This is the filter used to identify groups as an attribute of the user.
Enable LDAPS: Used to authenticate and authorize users when LDAP communication is transmitted over an SSL tunnel port 636 TCP. By default, the use of LDAPS is recommended to improve the security of the environment.
Enable TLS: Used to secure communication between LDAP clients and LDAP servers (See 3.4.1).
Once all the attributes for the UDS type have been defined, click on Accept to save it.
To verify the UDS connection, select and click on the Check status button.
In case the status is correct, the “Last status” column will display Ready:
4.5.5.5. Configuring LDAPS or TLS for Secure LDAP Communication
Note
This procedure is required in case you use a local Certificate Authority (CA).
If you want to use SSL or TLS for communication with the LDAP, you will need to perform some initial configuration to secure the SSL connection. This applies to both enabling LDAPS and enabling TLS in the UDS configuration.
1. Enable the Dynamic CA Configuration feature:
update-ca-trust enable
2. To obtain the public root CA, use the following command to view the Active Directory certificate information, where “server” is the FQDN or IP address of the server:
openssl s_client -showcerts -connect server: 636 </ dev / null | openssl x509 -text -noout
3. With the certificate information, obtain the URL to download the CA certificate based on the “Access to Authority Information: CA Issuers” section. If the above command does not work, request a public certificate file from administrators. The file would have to be similar to:
----- BEGIN CERTIFICATE -----
MIIDWTCCAkGgAwIBAgIQG5sNj3OqU69C1kh4 + Z6oMzANBgkqhkiG9w0BAQ0FADA /
MRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFDASBgoJkiaJk / IsZAEZFgRhY21lMRAw
DgYDVQQDEwdhY21lLUNBMB4XDTE5MTAyMTE0NTMzNVoXDTI0MTAyMTE1MDMzNVow
P...
----- END CERTIFICATE -----
4. Copy the CA Certificate to the /etc/pki/ca-trust/source/anchors/ directory :
cp CACERT.crt /etc/pki/ca-trust/source/anchors/
5. Update the CA trust database:
update-ca-trust extract
6. Check if certificate was correctly added to system:
trust list --filter=ca-anchors | grep "CA NAME" -i -A 2 -B 3
7. If you can’t see your CA, verify that the certificate has the CA Basic Constraint enabled:
openssl x509 -in <certificate to check> -purpose -noout -text
The output must contain:
X509v3 Basic Constraints: critical
CA:TRUE
4.5.5.5.1. LDAPS Configuration without Server Certificate Validation (Not Recommended)
In some circumstances, such as in a testing environment, it may be necessary to use LDAPS without validating the certificate, either because it is not available or because it is not required.
Note
This practice is not recommended in production environments.
To enable the functionality, execute the following steps:
1. Edit the /etc/openldap/ldap.conf file:
vim /etc/openldap/ldap.conf
2. Add the following parameter:
TLS_REQCERT never
4.5.5.5.2. 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.
Captive Configurations
4.5.5.6. Configuring Captive Sponsors
The primary role of a sponsor is to validate requests from users who want to register through a captive workflow. When a user goes through a workflow that requires sponsor email validation, a validation email will be sent to all configured sponsors. Sponsors must then approve the user’s request, granting them access to the network.
Navigate to the ON Captive > Captive sponsors section, to add, remove, or edit sponsors.
To add a new sponsor, click the Add new button. A pop-up window will appear, where you can enter the desired email. After entering the email, click Accept.
4.5.5.7. Creating Captive Workflows
A workflow is an authentication process that can be configured in the ON Captive > Captive workflows section.
To add a new workflow, click the Add new button.
You will see five different templates available:
Two of them are BYOD templates, one wired (dot1x-registered-users) and the other Wi-Fi connections (webauth-registered-users).
4.5.5.7.1. Wired BYOD Workflow
To create a wired workflow, the following parameters are required:
General tab
Name: Name of the workflow.
Description: Workflow description.
Available languages: Select all languages in which the workflow can be displayed.
Template: Workflow template. There are two templates for the Guest use case, one for wire and the other for Wi-Fi. We will also find two templates for the BYOD use case, one for wire and the other for Wi-Fi. And finally, we will find one for the OpenNAC Agent.
In this example, we have chosen the dot1x-registered-users template to create a wired workflow for a BYOD use case.
Options tab
Enable captcha: Allows the option to enable a captcha within the workflow
Available captcha characters: Specifies the characters that can appear in the captcha.
Workflow TTL (in seconds): The time limit, in seconds, for the workflow’s duration.
User connection TTL (in minutes): The maximum duration, in minutes, for a user’s connection.
Compliance tag: A tag that must match to grant network access. If the tag does not match, the user will be informed of the reason for access denial.
URL to redirect on toggle success: The URL to which the registered user is redirected once the workflow is completed.
Identification tab
There are two types of configurations available: user/password and SAML.
1. For the user/password type, a two-factor authentication method is available, which can be either email or SMS.
A. For email-based two-factor authentication, the following parameters can be configured:
Identification type: The type of identification, which will be user/password in this case.
2nd authentication factor: The type of second-factor authentication.
E-mail from: The email address that will send the email to the user.
User e-mail confirmation template: The template for the email.
User e-mail confirmation title: The title for the email.
B. For SMS two-factor authentication, the following parameters can be configured:
Identification type: The type of identification, which will be user/password in this case.
2nd authentication factor: The type of second-factor authentication, which will be SMS in this case.
SMS Type: The type of SMS, which will be SOAP in this case.
SMS Sender: The sender of the SMS.
SMS URL: The URL for the SMS service.
Send SMS in secure mode: Enables secure mode for SMS.
SMS User: The username for the SMS service.
SMS Password: The password for the SMS user.
SMS Message before PIN: The text that will precede the PIN.
SMS Message after PIN: The text that will follow the PIN.
Use proxy: Enables the use of a proxy and activates the proxy fields.
Proxy type: Selects the type of proxy, either HTTP or HTTPS.
Proxy URL: The URL for the proxy.
Proxy port: The port number for the proxy.
Proxy user: The username for the proxy.
Proxy password: The password for the proxy user.
2. For the SAML type, the following configuration is available:
The first module is called Service provider (SP) and includes the following fields:
Authentication source name: SP name.
Entity ID of the service provider (SP): URL of the SP. In this case, the core acts as an SP, that is why the entity ID is the core domain.
Entity ID of the IdP that the SP should contact: URL of the IDP that will contact the SP.
The second module is called Remote IDP and includes the following field:
Metadata: Metadata of the IDP. The metadata you should enter here can be found in the IDP.
The third module is called Federation (SP metadata) and we can find the link to get access to our SP metadata. We will only need to replace the captive_portal_ip_or_domain variable with the correct one when browsing the metadata.
Finally, the fourth module is called User attributes and includes the following fields:
User name attribute: Attribute that will return a user specific username.
E-mail attribute: Attribute that will return a user specific email.
User groups attribute: Attribute that will return a user specific groups.
Additional attributes: Permits to add new attributes with the specific item we want to get.
Agent tab
In this tab, you can enable the Agent for the workflow.
Enable OpenNAC agent: Activates the ON agent.
Timeout to check if agent is installed (in seconds): The timeout period for checking if the agent is installed.
Maximum number of checks to know if agent has been installed: The maximum number of checks to confirm agent installation.
Time to display a message once the installation is finished: The duration for which a message will be displayed upon completion of the installation.
Notification tab
In this tab, you can enable notifications for the user.
Notification type: The type of notification.
E-mail template: The template for the email notification.
E-mail title: The subject line for the email.
E-mail from: The sender’s email address.
E-mail to: The recipient’s email address.
Use sponsor as e-mail to: Enables sending the notification to the sponsors.
Use captive sponsors list: EEnables the use of the sponsor list in On Captive > Captive Sponsors. If this option is not enabled, the following fields must be filled out:
Sponsor data source: The source for the sponsors list.
Sponsor data source LDAP query: The LDAP query for the sponsors list source.
Sponsors: The sponsors who can validate the emails.
Form fields
In this tab, you can create forms that request fields in the workflow.
To add a new form, click on the Add new button:
Field: The name of the field.
Type: This pop-up menu contains a set of data types corresponding to the form field being created. The selected type must match the type of information provided by the user. For example, if the information is a username, the type must be String. If the information is a password, then the type must be Password, and so on.
Description: A meaningful description of the purpose of the form field.
Icon: The icon image that will be displayed in the Flags column of the form field. This helps users quickly identify the corresponding type of information.
Default value: The default information to be displayed in the field.
Required: Specifies whether this form field must be filled out by the user.
Enabled: Indicates whether the form field is enabled and will be displayed on the authentication screen along with other fields.
Validations: The type of validation to be performed by the ON Captive module during the authentication process to ensure that the information entered matches the expected input for this particular form field.
Custom properties: Specific additional properties that may be necessary for validating certain types of submitted data and/or for further verification.
Views tab
This tab allows the insertion of custom code that changes the presentation layer behavior of the Captive Portal web elements according to the specific needs of the customer.
To allow the insertion of code for each view, switch the flag, which is set to Use Default by default. This will change to Set Custom, allowing you to insert the custom view code.
Translations tab
This tab permits adding translations for the workflow name and description in the workflow presentation. The languages available are those selected in the General tab.
4.5.5.7.2. Wireless BYOD Workflow
To create a wireless workflow, the following parameters are required:
General tab
Name: Name of the workflow.
Description: Workflow description.
Available languages: Select all languages in which the workflow can be displayed.
Template: Workflow template. There are two templates for the Guest use case, one for wire and the other for Wi-Fi. We will also find two templates for the BYOD use case, one for wire and the other for Wi-Fi. And finally, we will find one for the OpenNAC Agent.
In this example, we have chosen the webauth-registered-users template to create a WiFi workflow for a BYOD use case.
Options tab
Enable captcha: Allows the enabling of a captcha in the workflow.
Available captcha characters: All the characters in this field can be used in the captcha.
Workflow TTL (in seconds): The time limit, in seconds, for the workflow duration.
WLC User connection TTL (in minutes): The maximum duration, in minutes, for a WLC connection. This should be synchronized with the WLC TTL to avoid desynchronization.
WLC Password type: The type of WLC password.
WLC Password length: The length of the WLC password.
WLC Configurations:Configuration settings for the WLC type. To add a new configuration, click on the Add new button:
Name: The name for the WLC configuration.
Type: The type of configuration. You can select from three templates (Aruba, Cisco, and Meraki) or choose “Other” to insert a custom one.
MAC request parameter: Parameter for the MAC request.
Callback URL request parameter: URL for the request parameter callback.
Callback URL prefix: URL for the prefix callback.
Callback URL suffix: URL for the suffix callback.
Redirect URL request parameter: URL for the request parameter redirect.
Error code request parameter: URL for the request parameter error code.
Username property name for WLC: WLC username.
Password property name for WLC: Password for the WLC username.
Additional properties to be sent on POST: Allows you to add new properties to the POST request.
Identification tab
There are two types of configurations available: user/password and SAML.
1. For the user/password type, a two-factor authentication method is available, which can be either email or SMS.
A. For email-based two-factor authentication, the following parameters can be configured:
Identification type: The type of identification, which will be user/password in this case.
2nd authentication factor: The type of second-factor authentication.
E-mail from: The email address that will send the email to the user.
User e-mail confirmation template: The template for the email.
User e-mail confirmation title: The title for the email.
B. For SMS two-factor authentication, the following parameters can be configured:
Identification type: The type of identification, which will be user/password in this case.
2nd authentication factor: The type of second-factor authentication, which will be SMS in this case.
SMS Type: The type of SMS, which will be SOAP in this case.
SMS Sender: The sender of the SMS.
SMS URL: The URL for the SMS service.
Send SMS in secure mode: Enables secure mode for SMS.
SMS User: The username for the SMS service.
SMS Password: The password for the SMS user.
SMS Message before PIN: The text that will precede the PIN.
SMS Message after PIN: The text that will follow the PIN.
Use proxy: Enables the use of a proxy and activates the proxy fields.
Proxy type: Selects the type of proxy, either HTTP or HTTPS.
Proxy URL: The URL for the proxy.
Proxy port: The port number for the proxy.
Proxy user: The username for the proxy.
Proxy password: The password for the proxy user.
2. For the SAML type, the following configuration is available:
The first module is called Service provider (SP) and includes the following fields:
Authentication source name: SP name.
Entity ID of the service provider (SP): URL of the SP. In this case, the core acts as an SP, that is why the entity ID is the core domain.
Entity ID of the IdP that the SP should contact: URL of the IDP that will contact the SP.
The second module is called Remote IDP and includes the following field:
Metadata: Metadata of the IDP. The metadata you should enter here can be found in the IDP.
The third module is called Federation (SP metadata) and we can find the link to get access to our SP metadata. We will only need to replace the captive_portal_ip_or_domain variable with the correct one when browsing the metadata.
Finally, the fourth module is called User attributes and includes the following fields:
User name attribute: Attribute that will return a user specific username.
E-mail attribute: Attribute that will return a user specific email.
User groups attribute: Attribute that will return a user specific groups.
Additional attributes: Permits to add new attributes with the specific item we want to get.
Agent tab
In this tab, you can enable the Agent for the workflow.
Enable OpenNAC agent: Activates the ON agent.
Timeout to check if agent is installed (in seconds): The timeout period for checking if the agent is installed.
Maximum number of checks to know if agent has been installed: The maximum number of checks to confirm agent installation.
Time to display a message once the installation is finished: The duration for which a message will be displayed upon completion of the installation.
Notification tab
In this tab, you can enable notifications for the user.
Notification type: The type of notification.
E-mail template: The template for the email notification.
E-mail title: The subject line for the email.
E-mail from: The sender’s email address.
E-mail to: The recipient’s email address.
Use sponsor as e-mail to: Enables sending the notification to the sponsors.
Use captive sponsors list: EEnables the use of the sponsor list in On Captive > Captive Sponsors. If this option is not enabled, the following fields must be filled out:
Sponsor data source: The source for the sponsors list.
Sponsor data source LDAP query: The LDAP query for the sponsors list source.
Sponsors: The sponsors who can validate the emails.
Form fields
In this tab, you can create forms that request fields in the workflow.
To add a new form, click on the Add new button:
Field: The name of the field.
Type: This pop-up menu contains a set of data types corresponding to the form field being created. The selected type must match the type of information provided by the user. For example, if the information is a username, the type must be String. If the information is a password, then the type must be Password, and so on.
Description: A meaningful description of the purpose of the form field.
Icon: The icon image that will be displayed in the Flags column of the form field. This helps users quickly identify the corresponding type of information.
Default value: The default information to be displayed in the field.
Required: Specifies whether this form field must be filled out by the user.
Enabled: Indicates whether the form field is enabled and will be displayed on the authentication screen along with other fields.
Validations: The type of validation to be performed by the ON Captive module during the authentication process to ensure that the information entered matches the expected input for this particular form field.
Custom properties: Specific additional properties that may be necessary for validating certain types of submitted data and/or for further verification.
Views tab
This tab allows the insertion of custom code that changes the presentation layer behavior of the Captive Portal web elements according to the specific needs of the customer.
To allow the insertion of code for each view, switch the flag, which is set to Use Default by default. This will change to Set Custom, allowing you to insert the custom view code.
Translations tab
This tab permits adding translations for the workflow name and description in the workflow presentation. The languages available are those selected in the General tab.
4.5.5.8. Customizing Captive Themes
You can create and modify different themes that will affect the appearance of the Captive Portal web interface.
Navigate to ON Captive > Captive themes>
To create a new Captive theme, click the Add new button. By default, the window displays the configurations related to the General tab:
You can customize multiple parameters:
General
Name: Enter a name for this Captive theme.
Description: Provide a meaningful description of the theme.
Logo: Defines the .png image to be used as the logo for the theme. By default, this is set to the OpenNAC logo.
Background: Defines the .png image to be used as the background for the theme. By default, this is the OpenNAC background image.
Icon: Defines the .ico image used as the favicon for the theme. By default, the OpenNAC favicon is used. The favicon appears in the browser’s address bar.
There are three buttons available for each field that allow for changing the images:
Upload file: Allows you to upload the desired logo image. The preview will be displayed in the square next to the field.
Remove file: Removes the uploaded element.
Set default file: Sets the file as the default for future themes.
CSS
From this tab, you can insert custom CSS code to modify the look and feel of the Captive Portal.
Header
From this tab, you can insert custom HTML code for the header of the Captive theme.
Footer
From this tab, you can insert custom HTML code for the footer of the Captive theme.
To complete the creation of the new Captive theme, click the Accept button.
To upload images for the theme, you can select an already created theme and click the Set images button.
Once the pop-up window appears, you will see all the uploaded images. You can edit the existing images and preview them by clicking the eye icon.
To upload a new image, click the Add new button. A dialogue will appear where you can name and describe the image and upload it.
Translations
You can also manage translations for the different Captive Portal workflows and sections. To do this, select a theme and click the Set translations button.
Once the pop-up window appears, you will see all the existing translations. You can edit them and preview the content by clicking the eye icon.
To translate a new section, click the Add new button.
From the pop-up window, you can select a module to translate. The content and associated text will appear in the field, where you can input your translations. Then, select the language you are translating to and provide a description if necessary.
E-mail templates
You can also configure e-mail templates or modify existing ones by editing the HTML code used in emails sent from the Captive Portal workflows. To do this, select a theme and click the Set e-mail templates button.
Once the pop-up window appears, you will see all existing templates for the workflows. You can edit and preview them by clicking the eye icon.
To configure a new email template, click the Add new button.
From the pop-up window, you can select a module to modify. You can then edit the module content in HTML format and add a description.
Apply themes
To apply the created theme to an instance, navigate to the instance in ON Captive > Captive instances and select the desired theme:
After applying the theme, navigate to the Captive Portal and refresh the browser to see the changes.
4.5.5.9. Creating Captive Instances
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.
BYOD Policies
4.5.5.10. Wired BYOD Policies
It is necessary to add different policies for the wired BYOD use case. Navigate to the ON NAC > Policies section. The following policies need to be set up:
Note
The order of the policies is important, starting from the most restrictive to the least restrictive.
4.5.5.10.1. Unknown Device Policy
The first policy to configure is the Unknown device. This policy matches all the devices connected via wired connections that do not meet the criteria of any other policies.
In the Preconditions: Source field, you need to set MAB.
This policy sends the device to a VLAN of type Registry, as the device needs to be registered.
4.5.5.10.2. BYOD Compliance Policy
The next policy to configure is BYOD Compliance. This policy matches all wired devices that have successfully passed the BYOD workflow with compliance.
For a device to be compliant, it must have the following tags:
ONC_WEBAUTH_APPROVED: Indicates the workflow is complete.
EPC_FULL_COMPLIANCE: Compliance tag that must align with the captive portal configuration.
ONC_CAPTIVE_REGISTERED: Indicates that the device has completed the BYOD workflow.
In the Preconditions: Source field, you need to set MAB.
This policy sends the device to a VLAN of type Service, granting the device access.
4.5.5.10.3. BYOD Quarantine Policy
The next policy to configure is BYOD Quarantine. This policy applies to all devices connected by wire that have passed the BYOD workflow with agent authentication.
After Agent authentication is enabled, a device should have the following tags:
ONC_WEBAUTH_APPROVED: Indicates the workflow is complete.
ONC_AGENT: Confirms successful agent authentication.
ONC_CAPTIVE_REGISTERED: Indicates the device is part of a BYOD workflow.
In the Preconditions: Source field, you need to set MAB.
This policy sends the device to a VLAN of type Quarantine, notifying the device of any missing requirements needed for compliance.
4.5.5.10.4. BYOD Without Agent Policy
The next policy to configure is BYOD Without Agent. This policy applies to all wired devices that have passed the BYOD workflow without Agent authentication.
The following tags are assigned to a device after it completes the workflow:
ONC_WEBAUTH_APPROVED: Indicates the workflow is complete.
ONC_CAPTIVE_REGISTERED: Confirms the device has gone through the BYOD workflow.
In the Preconditions: Source field, you need to set MAB.
This policy sends the device to a VLAN of type Service, notifying the device of any missing requirements needed for full compliance.
4.5.5.11. Wireless BYOD Policies
It is necessary to add different policies for the Wireless BYOD use case. Navigate to the ON NAC > Policies section. The following policies need to be set up:
Note
The order of the policies is important, starting from the most restrictive to the least restrictive.
4.5.5.11.1. Unknown Device Policy
The first policy to configure is the Unknown device. This policy matches all the devices connected via Wi-Fi connections that do not meet the criteria of any other policies.
In the Preconditions: User field, you need to set Supplicant User.
This policy sends the device to a VLAN of type Registry, as the device needs to be registered.
4.5.5.11.2. BYOD Compliance Policy
The next policy to configure is BYOD Compliance. This policy matches all devices connected via Wi-Fi that have successfully passed the BYOD workflow with compliance.
For a device to be compliant, it must have the following tags:
ONC_WEBAUTH_APPROVED: Indicates the workflow is complete.
EPC_FULL_COMPLIANCE: Compliance tag that must align with the captive portal configuration.
ONC_CAPTIVE_REGISTERED: Indicates that the device has completed the BYOD workflow.
You need to set the NDT_WIFI tag, which filters by network device type, along with the SSID of the WLC in the Preconditions: Network Devices section:
In the Preconditions: Sources field, you need to set Supplicant User.
This policy sends the device to a VLAN of type Service, notifying the device of any missing requirements needed for full compliance.
4.5.5.11.3. BYOD Quarantine Policy
The next policy to configure is BYOD Quarantine. This policy applies to all devices connected via Wi-Fi that have passed the BYOD workflow with agent authentication.
After agent authentication is enabled, a device should have the following tags:
ONC_WEBAUTH_APPROVED: Indicates the workflow is complete.
ONC_AGENT: Confirms successful agent authentication.
ONC_CAPTIVE_REGISTERED: Indicates the device is part of a BYOD workflow.
You need to set the NDT_WIFI tag, which filters by network device type, along with the SSID of the WLC in the Preconditions: Network Devices section:
In the Preconditions: Sources field, you need to set Supplicant User.
This policy sends the device to a VLAN of type Quarantine, notifying the device of any missing requirements needed for compliance.
4.5.5.11.4. BYOD Without Agent Policy
The next policy to configure is BYOD Without Agent. This policy applies to all devices connected via Wi-fi that have passed the BYOD workflow without Agent authentication.
The following tags are assigned to a device after it completes the workflow:
ONC_WEBAUTH_APPROVED: Indicates the workflow is complete.
ONC_CAPTIVE_REGISTERED: Confirms the device has gone through the BYOD workflow.
You need to set the NDT_WIFI tag, which filters by network device type, along with the SSID of the WLC in the Preconditions: Network Devices section:
In the Preconditions: Sources field, you need to set Supplicant User.
This policy sends the device to a VLAN of type Service, notifying the device of any missing requirements needed for full compliance.