4.2.4. Node Configuration
To follow this configuration process, all nodes required for this use case (ON Core and ON Analytics, ON Sensor and ON Agent) must have been properly deployed, following the node deployment and basic configuration section.
The UNAC network access control module allows us to control which devices and users can access the network and which ones cannot. It relays on the Segmentation module to determine which VLAN should they belong to, and the access restrictions to each of them depending on the needs or requirements associated with the defined security policies or business policies.
This process is carried out using mainly protocols such as 802.1x, and RADIUS based on AAA (Authentication,Authorization and Accounting), that is why the UNAC configuration process consists of 2 steps:
Choose scenario, User/Pass, Certificate, MAB (User database AD, LDAP, CA has to be configured)
Activate 802.1x in network and user devices (activate protocol and configure params)
Below are the steps for configuring the nodes required for the UNAC use case to become operational.
Note
Since the UNAC module can make use of some functionalities of network devices from different manufacturers, it is necessary that you have the necessary knowledge to configure these devices.
This section will show configuration examples for specific models. It is up to the users to extrapolate these configurations to the network devices they have available.
4.2.4.1. Network Device RADIUS permissions
When a user device connects to a network, the network device to which it connects must send an authentication request to the authentication server (ON Core). For this request to be accepted and processed by ON Core, it is necessary to configure the <clients.conf> file.
This file allows for control and restriction of RADIUS permissions, specifying which network devices and other authenticators are permitted to make RADIUS requests to the system. In this file, define all devices or network segments that have authorization to make such requests, along with the shared key each must use.
To add or modify new devices or network segments, edit the </etc/raddb/clients.conf> file:
client 192.168.0.0/16 {
secret = testing123
shortname = internal192168
}
client 172.16.1.0/24 {
secret = testing123
shortname = internal172161
}
Each “client” block requires three parameters:
client: The IP address of the host or network segment from which the requests will arrive.
secret: The RADIUS pre-shared key, used to authenticate requests.
shortname: Name to identify the client or network segment (identifier). This name is helpful in logs, making it easier to identify related information.
Additional networks or host IPs can be defined as needed. Ensure that the “secret” value in each block matches the shared-key configured on the respective network device.
After modifying the file, restart the RADIUS service on all worker nodes to apply the changes:
systemctl restart radiusd
4.2.4.2. 802.1x Authentication configuration
The system supports several authentication methods:
Supplicant for user credentials
Supplicant for team credentials
Supplicant for user certificate
Supplicant for equipment certificate
MAC-Address-Bypass
User credentials
Some of these methods may require additional system configuration, these configurations are detailed below:
4.2.4.2.1. Certificate Authentication
There is the option to perform authentications through certificates installed on end-user devices or devices that support this method. These certificates will undergo validation within the system during the authentication process, and their attributes may be utilized in the subsequent authorization process (policy evaluation).
Authentication through certificates can be configured in two ways:
Using certificates issued by an Internal Certificate Authority (CA)
Using certificates issued by an External Certificate Authority (CA)
Given that in environments where authentication by certificates is required, there is usually its own CA and certificate management by the organization, this is the most frequent option. Even so, the possibility of implementing certificate authentication through the system itself can be useful when testing or in lower-volume environments.
For instructions on setting up either type of CA, refer to the following sections:
4.2.4.2.2. Supplicant configuration for 802.1x Authentication
To enable authentication using 802.1x, it is essential to configure the supplicant service on client computers based on network requirements. The specific configuration varies depending on the authentication type and client characteristics. Below are examples for some widely used operating systems.
4.2.4.2.2.1. Windows
To enable 802.1x functionality on Windows computers, start the service responsible for managing this feature.
Access the services menu by pressing “Windows + R” and then opening “services.msc”:
In the list of services, select the “Wired AutoConfig” or “Automatic configuration of wired networks” and start the service:
Once the service is active, you can configure the supplicant on the corresponding network interface:
Navigate to Control Panel > Network and Internet > Network Connections.
Select the interface that you want to configure, right-click and choose Properties.
In the pop-up window, access the “Authentication” tab.
Choose the appropriate configuration based on the desired authentication type:
Authentication by user/computer
Authentication by certificate
For Windows, the Fast Reconnect functionality facilitates quicker connections through caching. Refer to the Setup with Windows Fast Reconnect for more information.
4.2.4.2.2.1.1. Authentication by user/device
To configure the supplicant for authentication by user and/or device, follow this recommended and widely used configuration. Ensure the supplicant is set up to perform authentication based on user and/or device credentials.This configuration is commonly recommended for its simplicity and effectiveness.
Note that there are alternative methods available, which may necessitate additional configuration in ON Core.
Enable IEEE 802.1X authentication: Activate the protocol for network media authentication.
Choose a network authentication method: Select the method to use for network authentication. in this case “Protected EAP”.
Remember my credentials for this connection each time I’m logged on: This flag allows the credentials to be stored and not asked again in future connections.
Fallback to unauthorized network access: This option allows the device port to be left open in case authentication fails. In this way we can perform a Mac Address Bypass if it is configured in the network electronics.
Note
To avoid being prompted for credentials every time you connect to the network, check the option “Remember my credentials for this connection each time I’m logged on.” This will save your credentials, eliminating the need for manual input with each connection.
Settings
In the settings of the selected method, you can customize the behavior of the supplicant to align with your specific environment.
Verify the server’s identity by validating the certificate: This item specifies that the client verifies that server certificates presented to the client computer have the correct signatures, haven’t expired, and were issued by a trusted root certification authority (CA). Disabling this check box causes client computers to be unable to verify the identity of your servers during the authentication process. If server authentication does not occur, users are exposed to severe security risks, including the possibility that users might unknowingly connect to a rogue network. It is possible that if you mark this one but you do not specify any Trusted Root Certification Authorities, the authentication can fail.
Connect to these servers: Allows you to specify the name for RADIUS servers that provide network authentication and authorization. You must type the name exactly as it appears in the subject field of each RADIUS server certificate or use regular expressions (regex) to specify the server name.You can also include a ; to separate multiple servers. It is possible that if you do not specify any, the authentication will fail.
Trusted Root Certification Authorities: Select which CAs can be valid when verifying the identity of the server.
SelectAuthentication Method: Define the method used for authentication. In this case “Secured Password (EAP-MSCHAP v2)”.
Enable Fast Reconnect: This reduces the delay in time between an authentication request by a client and the response by RADIUS server, and allows wireless clients to move between access points without repeated requests for authentication.
Disconnect if server does not present cryptobinding TLV: Specifies that connecting clients must end the network authentication process if the RADIUS server does not present cryptobinding Type-Length-Value (TLV)
Enable Identity Privacy: Specifies that clients are configured so that they cannot send their identity before the client has authenticated the RADIUS server, and optionally, provides a place to type an anonymous identity value.
Additional Settings
In the Additional Settings, you can choose the type of credentials for authentication—either user credentials (prompted at each connection or saved using “Save credentials”) or computer credentials (utilizing the computer’s credentials).
You can also configure “Authentication of users or device” to be carried out automatically.
4.2.4.2.2.1.2. Authentication by certificate
To set up the supplicant for authentication by user and/or device through a certificate, follow this recommended and widely used configuration. Note that there are alternative methods available, which may require additional configuration in ON Core.
It’s crucial to highlight that, for certificate-based authentication, the certificates and the certifying entity (CA) must be pre-installed on the computer.
Enable IEEE 802.1X authentication: Activate the protocol for network media authentication.
Choose a network authentication method: Select the method to use for network authentication. in this case “Smart Card or other certificate”.
Remember my credentials for thus connection each time I’m logged on: This flag allows the credentials to be stored and not asked again in future connections.
Fallback to unauthorized network access: This option allows the device port to be left open in case authentication fails. In this way we can perform a Mac Address Bypass if it is configured in the network electronics.
Note
To avoid being prompted for credentials every time you connect to the network, check the option “Remember my credentials for this connection each time I’m logged on.” This will save your credentials, eliminating the need for manual input with each connection.
Settings
In the settings of the selected method, you can customize the behavior of the supplicant to align with your specific environment.
Verify the server’s identity by validating the certificate: This item specifies that the client verifies that server certificates presented to the client computer have the correct signatures, haven’t expired, and were issued by a trusted root certification authority (CA). Disabling this check box causes client computers to be unable to verify the identity of your servers during the authentication process. If server authentication does not occur, users are exposed to severe security risks, including the possibility that users might unknowingly connect to a rogue network. It is possible that if you mark this one but you do not specify any Trusted Root Certification Authorities, the authentication can fail.
Connect to these servers: Allows you to specify the name for RADIUS servers that provide network authentication and authorization. You must type the name exactly as it appears in the subject field of each RADIUS server certificate or use regular expressions (regex) to specify the server name.You can also include a ; to separate multiple servers. It is possible that if you do not specify any, the authentication will fail.
Trusted Root Certification Authorities: Select which CAs can be valid when verifying the identity of the server.
Do not prompt user to authorize new servers or trusted certification authorities: Prevents the user from being prompted to trust a server certificate if that certificate is incorrectly configured, is not already trusted, or both (if enabled).
Use a different user name for the connection: Specifies whether to use a user name for authentication that is different from the user name in the certificate.
Additional Settings (Certificate Selection)
You can manually specify whether to use computer or user certificates in the “Additional settings” section within the network adapter properties window.
Certificate Issuer: Specifies whether Certificate Issuer filtering is enabled.
Certificate Issuer list: Select the CAs by which the certificates that will be presented for authentication have been signed.
Extended Key Usage (EKU): You can select All Purpose, Client Authentication, Any purpose, or any combination of these. Specifies that when a combination is selected, all the certificates satisfying at least one of the three conditions are considered valid certificates for authenticating the client . If EKU filtering is enabled, one of the choices must be selected; otherwise, the OK command control is disabled.
All Purpose: Specifies that (when selected) certificates having the All Purpose EKU are considered valid certificates for the purpose of authenticating the client to the server.
Client Authentication: Specifies that (when selected) certificates having the Client Authentication EKU, and the specified list of EKUs are considered valid certificates for the purpose of authenticating the client to the server.
4.2.4.2.2.2. Linux (Ubuntu)
This example will explain how to configure an Ubuntu computer, this configuration can be replicated in several similar distributions.
Wired:
To configure the supplicant in Ubuntu, we must access the network section in the upper bar and select the desired interface and then Wired Settings. In the pop-up window that will open, we must select the network to which we want to configure the supplicant and click “Edit”.
A new window will open with the properties of the connection and in the “Security” tab we will have to configure the supplicant. The configuration shown below is recommended, although it can be adjusted to the needs of each case.
User Authentication:
To configure 802.1x to perform authentication with credentials we will perform the following configuration:
Authentication: Protected EAP
CA certificate: in case of validating the identity of the server, here we must indicate the CA used for validation.
No CA certificate is required: If we do not want to validate the identity of the server, we must mark this check.
Inner Authentication: the authentication method will be MSCHAPv2
Username/Password: Credentials used for authentication.
Certificate Authentication:
To configure 802.1x to perform authentication with certificates we will perform the following configuration:
Authentication: TLS
Identity: identity for authentication, this information is not relevant when authenticating against OpenNAC.
User certificate: Certificate that will be used to authenticate against OpenNAC.
CA certificate: in case of validating the identity of the server, here we must indicate the CA used for validation.
No CA certificate is required: If we do not want to validate the identity of the server, we must mark this check.
Private key: private key of the client certificate.
Private key password: encryption password for the private key of the client certificate.
WiFi:
To configure the supplicant in Ubuntu, we must access the network section in the upper bar and select “Edit Connections…”. In the pop-up window that will open, we must select the network to which we want to configure the supplicant and click “Edit”. A new window will open with the properties of the connection and in the “Security” tab we will have to configure the supplicant.
The configuration shown below is recommended, although it can be adjusted to the needs of each case.
4.2.4.2.2.3. MacOS
This example will explain how to configure the supplicant in MacOS.
Access the network section in the upper bar and select “Network preferences panel…”.
In the pop-up window displayed, select the network to which you want to configure the supplicant and click on “Advanced”.
A new window displaying the properties of the connection will open. In the “802.1X” tab, configure the supplicant for automatic connection by enabling the “Enable automatic connection” option.
4.2.4.2.3. Deploy 802.1x Configuration via GPO (Windows)
By using GPO (Group Policy Object) we can define the supplicant configuration for Windows machines that are located in a managed domain.
This will allow us to deploy the configuration massively and equally on all devices.
To do this we must follow the following steps on the domain controller:
Open the Group Policy Management:
Right click on Group Policy Objects and click “New”:
Define a name for the GPO and click “OK”:
Select the GPO from Group Policy Objects, in the “Security Filtering” section, Add and Remove users, groups, and computers that the GPO should apply to:
Right-Click the GPO, and click “Edit”. Configure the policies you want to apply in the Computer and/or User Configuration.
Configure the 802.1x Policy
5.1. Navigate to “Computer Configuration > Policies > Windows Settings > Security Settings > System Services”
Locate the Wired AutoConfig service and click to edit
5.2. Select “Define this policy setting” and set as “Automatic” as startup mode:
5.3. Navigate to “Computer Configuration > Policies > Windows Settings > Security Settings > Wired Network (IEEE 802.3) Policies”
Right click and select “Create A New Wired Network Policy for Windows Vista and Later Releases”:
5.4. Name the policy and set a Description:
5.5. Go to the “Security” tab and configure the supplicant based on the previous explanation about Windows Supplicant.
5.6. Click “Apply” and “OK” to complete the configuration
Now you need to link the GPO to the OU or Domain you want to apply. Right-click to the OU or Domain an click “Link an Existing GPO…”, then select the GPO , and click “OK”.
The GPO will be added to the defined OU or domain and will be applied at next policy update:
4.2.4.2.4. Network Device Configuration
The network devices must be configured to use the UNAC case, they are usually those through which the endpoint devices (PCs, printers, mobiles, etc.) access. These are usually Access Switches, APs, and AP Controllers.
The basic configuration of these devices is 802.1x and RADIUS. The UNAC module allows us to work with those network devices compatible with the protocols described above regardless of the brand and model. Additionally, there are a series of tested and approved devices for complete integration with the solution, which has specific guides for their configuration. Otherwise, it will be the user who must determine the relevant configuration.
The recommended configuration for network devices includes the following points:
802.1x configuration (wired networks)
RADIUS configuration
CoA configuration (Change of Authorization)
SNMP configuration
Default VLAN definition
Critical VLAN definition
Optional:
Guest VLAN definition
VoIP VLAN definition
4.2.4.2.5. User authentication using Kerberos traffic
In some environments where Windows user authentication is performed using Kerberos, it is possible to integrate such authentication with the UNAC module.
Note
To perform authentication through Kerberos traffic, it is necessary to deploy and configure the ON Sensor and ON Analytics node. This will take care of collecting and detecting Kerberos traffic.
This authentication works as follows:
When a device without a supplicant connects to the network, it authenticates itself to the switch using MAB at boot time.
The user will log in with their Windows account.
By means of the traffic sniffed by ON Sensor, we will be able to see and identify the Kerberos ticket (It is necessary to deploy ON Sensor).
In ON Core, we will associate the session with the user that we have seen in the Kerberos ticket.
A policy reassessment will be generated for that session so that, if necessary, the pertinent characteristics will be applied to the session (VLAN, Security Profiles, etc).
To perform the necessary configuration to implement this functionality, it will be necessary to follow the steps in the following documentation:
Deployment of Nodes (ON Core, ON Analytics, ON Sensor)
General Visibility configuration
Join ON COre to Active directory domain
4.2.4.2.6. Authentication for VPN Gateway
The UNAC module allows us to use as an authentication backend for VPN Gateways, both SSL-VPN and IPSEC, using the RADIUS protocol. These authentications are carried out by username and password.
Even though the use of external VPN Gateways is possible, we recommend using the 2SRA module for remote access to the network.
ON Core configuration:
First, it is required to allow VPN access, go to the /etc/raddb/huntgroups file, in this file we must add the VPN Gateway to the vpn group by adding the following line to the file:
[root@oncore ~]# vim /etc/raddb/huntgroups
vpn NAS-IP-Address == <VPN_IP>
This hunt group can be changed and is related to the Radius module of the system, it is defined in /etc/raddb/mods-available/opennac with the following parameters, vpnHuntgroupName = vpn:
[root@oncore ~]# cat /etc/raddb/mods-available/opennac | grep vpnHunt
vpnHuntgroupName = vpn
Since the VPN Gateway will make RADIUS requests to the system, we will need to add it as a client.
To do this, we go to the /etc/raddb/clients.conf file, and add the new client:
[root@oncore ~]# vim /etc/raddb/clients.conf
Client <VPN_IP> {
secret = <presharedKey>
shortname = <Identificador_VPN>
}
VPN configuration:
Once ON Core is configured, we must configure the VPN Gateway to perform authentications against the system.
4.2.4.2.7. Notification service configuration
4.2.4.2.8. Setup with Windows Fast Reconnect
PEAP fast reconnection is desirable in applications such as wireless roaming. This feature allows you to resume sessions without completing a full authentication.
TLS session keys can be cached by the client and server and used to reduce the time between an authentication request from the client and the response from the Radius server.
To configure this functionality in the system it is necessary to make certain modifications.
Enable EAP-TLS cache in the /etc/raddb/eap.conf configuration file:
eap {
...
tls {
...
cache {
enable = yes
...
}
}
}
The lifetime and max_entries properties, within the cache section, are set to default values. We can adjust them depending on the environment.
Enable the use_tunneled_reply property in /etc/raddb/eap.conf, to send username-based response attributes within the tunnel:
eap {
...
peap {
...
use_tunneled_reply = yes
...
}
}
Windows supplicant configuration
Select the Enable Fast Reconnect property, in the EAP Protected Properties window (1.6.1.2).