4.5.2. Deployment Steps

To ensure the proper functionality of the deployed use case, it is crucial to meticulously follow the steps outlined. Keep in mind that these steps may vary based on the specific requirements and needs of your case.

Below, you will find a breakdown of both mandatory and optional steps, with the understanding that their applicability depends on your unique circumstances.

Architecture

  • Architecture: This section outlines the nodes necessary for the functioning of the use case, providing essential information related to its architecture. You can find a detailed explanation of the deployment of each of the nodes in Deployment and basic configuration

Configuration

Depending on the type of network devices used for deployment:

  • Cable - Configuration: If you are deploying the captive portal with wired type network devices (Switch) it will be necessary to carry out the pertinent configuration.

  • Wifi - Configuration: If you are deploying the captive portal with wireless type network devices (AP/WLC) it will be necessary to carry out the relevant configuration.

Optional:

Administration

  • Define the User Data Sources: Depending on the needs of the deployment. In case of authenticating clients through an external data source (AD or LDAP), it will be necessary to add this authentication sources.

  • Create Network Devices in the CMDB: Within the CMDB it will be necessary to register the network devices and their configurations so that they work correctly with OpenNAC Enterprise.

  • Create Captive Workflow: Captive portal workflows define the process that a user must go through in order to access services. These may include username/password authentication, saml, access notifications, ON Agent installation, etc.

  • Create Captive Domain: Captive dominions allow us to group various workflow to give users access flexibility depending on access levels, types of authentication, etc.

  • Create Captive Instance: The instance is the highest point in the configuration of a captive portal. It defines the characteristics and the location of the portal itself. This includes the address of the server that acts as the captive portal, the domain used, the theme, etc.

Depending on the type of network devices used for deployment:

Captive portal access requires a minimum policy configuration in OpenNAC Enterprise to manage records and control permissions. The policies can be different depending on the type of flow and network device that we are using:

Optional:

  • Join ON Core to Active Directory domain: When we use 802.1x authentication against an active directory, it may be necessary for the ON Core servers to be registered in the domain. This is because the active directory must accept the authentication request. This is mainly necessary when using MSCHAP type 802.1x authentication.

  • Manage Captive Sponsors: In some captive portal flows, it is required the validation of access by the “sponsors”. We must indicate which are these sponsors in case of using this functionality.

  • Create Captive Theme: Optionally, with the use of themes, we can customize the aesthetic appearance of the captive portals that we display (images, texts, html formats, etc.)

Operation

  • Operation : In this step, we will start operating the use case and checking that all the functionalities are working as expected. If we find some unexpected behavior we can go to the troubleshooting step in order to identify and fix the issue.

Monitoring

  • Monitoring : See how the data is being ingested and saved in ON Analytics. To check this, open the different visualizations available for this use case.

Troubleshooting