4.2.4. 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:

1. Choose scenario, User/Pass, Certificate, MAB (User database AD, LDAP, CA has to be configured)

2. Activate 802.1x in network and user devices (activate protocol and configure params)

Below are the steps for configuring the nodes and the specific details of the Administration Portal 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 us to control and restrict Radius permissions. Choose which network devices and other authenticators can make Radius requests to the system. In this file, we will define all those devices or network segments that have permission to make such requests, as well as the shared key that each of them must use.

To add or modify new devices or network segments we must 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
}

For each “client” block, 3 points must be taken into consideration:

• client: IP of the host or network segment from which the requests will arrive.

• secret: Pre-shared key of radius, this is the password to verify the requests.

• shortname: Name to identify the client or network segment (identifier). This name is important as it will be included in the logs and can help us identify the information more easily.

Here we can define additional networks or host IPs depending on the needs. Keep in mind that the “secret” value of each of the blocks must match the value of the shared-key defined in the configuration of the network device itself.

Once the file has been modified, we must restart the radius service to apply the changes (all worker nodes):

systemctl restart radiusd

4.2.4.2. 802.1x Certificate configuration in ON Core

The system supports several authentication methods, these can be:

• 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:

1. Using certificates issued by an Internal Certificate Authority (CA)

2. 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.

4.2.4.2.1.1. Certificates issued by an Internal CA

When an ON Core node is deployed from an OVA, it likely has expired internal certificates that will need to be renewed.

Certificate renewal

1. Go to the certificates folder /etc/raddb/certs/ and delete the old certificates and counters:

cd /etc/raddb/certs
rm -f *.pem *.der *.csr *.crt *.key *.p12 serial* index.txt*
make destroycerts

2. Define the property default_days in each CNF file (ca, server and client), to indicate the validity of the certificates. By default, it is set as 60 days. If you wish, you can modify the information related to the organization and passwords.

vim <file>.cnf

3. Run the bootstrap file, to generate the CA and server certificates:

cd /etc/raddb/certs
./bootstrap

Generate client certificates

1. To generate client certificates, provide a unique email address and common name in the client.cnf file, and generate the certificate with the following command:

make client

2. Install the generated client certificate (client.p12) on the client intended for authentication. On the client side, configure the supplicant to perform authentication using the certificate.

4.2.4.2.1.2. Certificates issued by an external CA

If your infrastructure already includes a Certificate Authority (CA) where UNAC will be deployed, you can utilize it to sign and use certificates for authentication.

For this purpose, the following certificates, provided by the CA, are required:

• CA certificate (if there is a PKI structure with several certificates, it is recommended that all of them be provided).

• Server certificate signed by the CA.

• Client certificates.

You can configure the server certificate with external CA through the Configuration Wizard: Radius Certificate Wizard

Note

To install the CA on the server we must have said CA in .pem format, if there is a PKI structure with multiple certifying entities, it is advisable to consolidate them into a single .pem file. You can obtain them in a different format and then proceed with the necessary conversion.

Installing the existing CA on ON Core

To configure the existing CA in the ON Core server, you just need to move and overwrite the currently installed CA:

cp <External_Complete_CA>.pem /etc/raddb/ca.pem

Creation of CSR (Certificate Signing Request)

1. To obtain a valid ON Core server certificate, generate a Certificate Signing Request (CSR) file (.csr) so that the certifying entity can deliver the signed certificate.

Eliminate all those certificates that exist in the RADIUS configuration, for this:

cd /etc/raddb/certs
make destroycerts

2. To generate the CSR, make modifications to the /etc/raddb/certs/server.cnf file. Ensure to adjust all necessary attributes according to the information provided by the client:

• Default_days: Certificate validity days.

• Input_password: Certificate input password.

• Output_password: Certificate output password.

• CountryName: Country code in two letters (eg ES).

• StateOrProvinceName: Name of the state or province.

• LocalityName: Name of the locality.

• OrganizationName: Name of the organization.

3. Once modified with the necessary information, save the file and generate the CSR file based on it. To do this, execute the following command:

make server.csr

4. Submit the /etc/raddb/certs/server.csr file to the certifying entity for signing. Upon completion, acquire a new certificate in the .pem format issued by the CA. If needed, you can obtain certificates in a different format and proceed with subsequent conversion steps.

5. Install and configure the certificate in the ON Core, by overwriting the existing certificate:

cp server.pem /etc/raddb/server.pem.bkp
cp <New_Server_Cert>.pem /etc/raddb/server.pem

6. Once the certificate has been overwritten, modify the RADIUS configuration by editing the /etc/raddb/radius.conf file. Specify the password of the new certificate:

# OpenNAC variables
opennac_certificate_file = "server.pem"
opennac_certificate_password = "<Server_Certificate_Password>"

Warning

If you have modified the name of the certificate in the previous step leaving it as “server.pem” it will not be necessary to modify the “opennac_certificate_file” variable. If the file name does not match, it will need to be modified.

7. Generate the dh and the random files:

make dh
make random

8. Finally, make sure that all the files inside /etc/raddb/certs have permissions for “root:radiusd” and restart the service:

chown root:radiusd /etc/raddb/certs/*
systemctl restart radiusd

If there is any problem with the certificates, the RADIUS service will NOT start. See the RADIUS logs section for more information.

4.2.4.3. 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.3.1. Windows

To enable 802.1x functionality on Windows computers, start the service responsible for managing this feature.

1. Access the services menu by pressing “Windows + R” and then opening “services.msc”:

2. 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:

3. Navigate to Control Panel > Network and Internet > Network Connections.

4. Select the interface that you want to configure, right-click and choose Properties.

5. 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.3.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.3.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.3.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.3.3. MacOS

This example will explain how to configure the supplicant in MacOS.

1. Access the network section in the upper bar and select “Network preferences panel…”.

2. In the pop-up window displayed, select the network to which you want to configure the supplicant and click on “Advanced”.

3. 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.4. 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:

1. Open the Group Policy Management:

2. Right click on Group Policy Objects and click “New”:

3. Define a name for the GPO and click “OK”:

1. 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:

1. 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

1. 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”.

7. The GPO will be added to the defined OU or domain and will be applied at next policy update:

4.2.4.5. 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.6. 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:

1. When a device without a supplicant connects to the network, it authenticates itself to the switch using MAB at boot time.

2. The user will log in with their Windows account.

3. 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).

4. In ON Core, we will associate the session with the user that we have seen in the Kerberos ticket.

5. 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.7. 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.8. Notification service configuration

Optionally, the system allows notifying by email when a policy is executed. As these notifications are made via emails, it will be necessary to configure the postfix service.

We can configure notifications for different email services. For this, you need to have the configuration data of the corporate mail service, with email account, password, server data, etc.

Here we will explain the basic configuration for SMTP Relay, and then Postfix configuration for notifications via Gmail and Office 365. In both cases will use the TCP/587 port.

4.2.4.9. Configuring SMTP Mail Relay

In this section we will configure the SMTP server in the ON Core so that it can send emails.

1. Connect via SSH to ON Core.

2. Update the system and install the necessary packages:

dnf update && dnf install postfix mailx cyrus-sasl cyrus-sasl-plain

SMTP Configuration:

There are two options for relaying the mail service: with authentication and without authentication.

When relaying without authentication, we utilize the SMTP protocol, and the configuration is as follows:

1. Configure postfix. In the relayhost section, add or modify the following lines in the /etc/postfix/main.cf` file :

relayhost=[smtp.example.com]:25
     myhostname = principal.acme.es

Where:

• relayhost: Specifies the mail relay host and port number. The hostname will be enclosed in parentheses to specify that an MX lookup is not required.

• myhostname: Hostname of the server running the postfix service.

2. Restart postfix service and enable auto startup:

systemctl enable postfix && systemctl start postfix

3. Send a test mail to verify the configuration:

mail -s "Test subject" recipient@domain.com < /dev/null

Where:

• recipient@domain.com: Replace this with the recipient’s email address.

Keep in mind that each email service will have specific configurations. In the following sections, we will provide the Postfix configurations for Gmail and Office 365.

4.2.4.9.1. Configuring Envelope Rewriting

By default, the envelope sender mail address of messages sent by OpenNAC via postfix service is set to the user apache, which is the user that runs the HTTPD service.

Depending on how the relay host’s administrator has configured it, certain security options or anti-spam rules may check if the sender mail address in the “From:” field matches the address in the envelope of the message. This can cause the relay host to reject mail messages from ON Core servers if the addresses are not identical.

As observed several times in production environments, the rejection of such messages often occurs because the standard mail address of the HTTPD user is not recognized as an authorized sender by the relay host.

To prevent this happen, we strongly recommend you perform additional steps in the postfix configuration.

Note

Perform the following configurations regardless of the type of relay host (Gmail, Office 365 or Microsoft Exchange).

1. Add a new line at the end of the /etc/postfix/canonical file, according to the example below.

// my-fixed-envelope-sender@example.org

• Replace the example email address with the actual sender email address of the organization.

2. Add the following lines to the /etc/postfix/main.cf file:

canonical_maps = regexp:/etc/postfix/canonical
canonical_classes = envelope_sender

3. Restart the postfix service:

service postfix restart

4.2.4.10. Postfix for emailing via Gmail

1. Update the system and install the necessary packages:

dnf update && dnf install postfix mailx cyrus-sasl cyrus-sasl-plain

2. Set up authentication with Gmail. Edit or create the /etc/postfix/sasl_passwd file and add the following line at the end:

[smtp.gmail.com]:587 <UserName@gmail.com>:<Password>

Where:

• username@gmail.com: mail account

• password: mail password

3. Configure postfix. In the /etc/postfix/main.cf file, apply the following configurations for the relayhost section:

relayhost = [smtp.gmail.com]:587
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_security_options =
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_CAfile = /etc/ssl/certs/ca-bundle.crt

• relayhost: Specifies the mail relay host and port number. The hostname will be enclosed in parentheses to specify that an MX lookup is not required.

• smtp_use_tls: Enables transport layer security.

• smtp_sasl_auth_enable: Enable SASL authentication.

• smtp_sasl_security_options: This should be left empty to ensure that incompatible security options are not used.

• smtp_sasl_password_maps: Specifies the password file to use. This is the file created in the Postfix configuration.

• smtp_tls_CAfile: Specifies the list of certificate authorities to use when verifying the identity of the server.

See an example of this configuration below:

4. If your mail service is NOT authenticated, you should also edit the myhostname attribute of the /etc/postfix/main.cf file with the name of your email domain.

myhostname = mydomain.tld

5. Compile and hash the contents of the /etc/postfix/sasl_passwd file:

postmap /etc/postfix/sasl_passwd
postmap hash:/etc/postfix/sasl_passwd

6. Restart the postfix service and enable autostart:

systemctl restart postfix && chkconfig --add postfix

7. In case of failure, perform the service shutdown and startup manually:

systemctl stop postfix
systemctl start postfix

Note

By default, Gmail only allows logins from secure connections.

To enable sending emails, it is necessary to change the settings in the Gmail account by enabling “Allow less secure applications”. For more information on how to do this, please review the information at the following link: https://support.google.com/accounts/answer/6010255?hl=en

8. Send a test mail to verify the configuration:

mail -s "Test subject" <recipient>@<domain.com> < /dev/null

Where:

• recipient@domain.com: Replace this with the recipient’s email address.

9. To view all mail logs and other message information:

tail -f /var/log/maillog

4.2.4.11. Postfix for emailing via Office 365

1. Update the system and install the necessary packages:

dnf update
dnf install postfix cyrus-sasl-plain mailx

2. Set up authentication with Office365. Edit or create the /etc/postfix/sasl_passwd file and set the credentials:

[smtp.office365.com]:587 <UserName>@<DomainName>:<Password>

3. Configure postfix. In the /etc/postfix/main.cf file, apply the following configurations for the relayhost section:

relayhost = [smtp.office365.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_generic_maps = hash:/etc/postfix/generic
smtp_tls_security_level = may
smtp_sasl_security_options = noanonymous

• relayhost: Specifies the mail relay host and port number. The hostname will be enclosed in parentheses to specify that an MX lookup is not required.

• smtp_sasl_auth_enable: Enable SASL authentication.

• smtp_sasl_password_maps: Specifies the password file to use. This is the file created in the previous step.

• smtp_generic_maps: Optional lookup tables that perform address rewriting on the Postfix SMTP client, typically to transform a locally valid address to a globally valid address when sending mail over the Internet.

• smtp_tls_security_level: By specifying a non-empty value, this overrides the deprecated smtp_use_tls, smtp_enforce_tls, and smtp_tls_enforce_peername parameters.

• smtp_sasl_security_options: This should be left empty to ensure that incompatible security options are not used.

See an example of this configuration below:

4. Compile and hash the contents of the /etc/postfix/sasl_passwd file:

postmap /etc/postfix/sasl_passwd
postmap hash:/etc/postfix/sasl_passwd

5. Change the file permission:

chown root:postfix /etc/postfix/sasl_passwd
chmod 640 /etc/postfix/sasl_passwd

6. Configure the /etc/postfix/generic file to be able to send email from a valid user:

/.*/ <UserName>@<DomainName.tld>

7. Change the permission of the /etc/postfix/generic file, compile, and hash:

chown root:root /etc/postfix/generic
chmod 0600 /etc/postfix/generic
postmap /etc/postfix/generic
postmap hash:/etc/postfix/generic

8. As an optional configuration, if you want to send all internal system messages to an external mailbox, change the root alias to your email address in /etc/aliases. This way, all messages sent to root will be forwarded to the system reporting address.

mailer-daemon:  postmaster
postmaster:    root
root:         <UserName>@<Domain.com>

9. Save and exit the file. Run the newaliases command to apply the changes.

10. Restart the postfix service and enable autostart:

systemctl restart postfix && chkconfig --add postfix

11. In case of failure, perform the service shutdown and startup manually:

systemctl stop postfix
systemctl start postfix

12. Send a test mail to verify the configuration:

mail -s "Test subject" <recipient>@<dominio.com> < /dev/null

Where:

• recipient@domain.com: Replace this with the recipient’s email address.

13. To view all mail logs and other message information, run:

tail -f /var/log/maillog

4.2.4.12. 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).