4.5.2. Deployment Steps

To ensure that the use case that we are deploying works correctly, it is necessary to carefully follow the steps we indicate. These may change depending on the requirements and needs in our case.

The mandatory and optional steps are detailed below. Remember it will depend on your specific case.

Architecture

  • Architecture: The first step is the deployment of the nodes needed for this use case. Here we will find the necessary information related to the architecture of the use case. 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 : At this point we will see how the data is being ingested and saved in ON Analytics. To check this we can open the different visualizations available for this use case.

Troubleshooting