1.2.9. Events

An “event” in OpenNAC refers to a specific occurrence or activity related to a device’s interaction with the system. These events are logged and can be viewed in the Policy Evaluation View under Business Profiles.

To view the events a device has gone through, navigate to ON NAC > Business Profiles and in the Policy column, click on the eye icon. It will display the Policy evaluation View where you can see the last 10 events registered in the ON Core.

A device can appear listed in OpenNAC Core through the different events (sources) listed below:

  • 802.1x: When the OpenNAC RADIUS server receives an OpenNAC authentication you will see this device. Moreover, the switch will also send information about accounting events. These authentications can occur with users, hosts, or certificates.

    • 802.1x User: 802.1x authentication using a user account

    • 802.1x Host: 802.1x authentication using a computer account

    • 802.1x User Certificate: 802.1x authentication using a user account with a certificate

    • 802.1x Host Certificate: 802.1x authentication using a a computer account with a certificate

  • MAB: When a end point accesses the network by authenticating through its MAC address.

  • SNMP Trap: Currently OpenNAC works with the version SNMPv1 & SNMPv2. In addition to having this technology, the network device must be able to send the MAC address of the device that has been connected (MAC learn traps).

  • Visibility: The OpenNAC Sensor will be able to visualize devices connected to the network through the traffic obtained using a span port configured in the network devices.

  • VPN: When accessing the network through a VPN Gateway that operates with OpenNAC.

  • USER: When the authentication process is made through a user (not supplicant). Normally used for network devices, monitors, users, or for test purposes.

  • IpMac: It associates an IP with a device. This is done using the device’s MAC. Furthermore, it can fingerprint it and obtain information such as its name and its operating system (OS).

  • IPSESSION: It is similar to the IP event, but instead of identifying the device by its MAC, it does it by using the connection’s name, the network device establishing the connection, and the port.

  • PLUGIN: It identifies the execution of a plugin which was previously defined in the policy.

  • INFO: This event shows that additional information was received. For example, this can be information about the device’s OS obtained when a device accessed the captive portal. This event can come from a wide range of sources, such as the Sensor, the Captive Portal, etc.

  • AGENT: When information is received from the OpenNAC’s Agent installed in the user’s device.

  • USERIN: When a user disconnection is detected. For example, the Agent or the sensor detects the login. This “login” information is then added.

  • USEROUT: When a user connection is detected. For example, the Agent or the sensor detects the logout. This “logout” information is then added.

  • USERLCK: When a “user session lock” is detected, (normally by the Agent) this “lock” information is then added. When the user is “unlocked” we will receive a “USERIN”.

  • TREQ: When a toggle request is requested from the web interface.

  • TOGGLE: When a toggle is executed in a network device and waits until the connection is re-established. If the network device’s configuration is not correct, the toggle will not occur and thus, it will show that the petition was requested but the connection was not re-established.

  • TDROP: When a toggle petition is received, but another toggle event was previously sent, this new petition is dropped as it cannot be applied. This occurs because there is no need to apply this new petition while the old petition has not been executed yet.

  • QRNT: When the device has been placed in quarantine.

  • DQRNT: When the device has been removed from quarantine.

  • INV_AGENT: Detailed information is received from the OpenNAC’s agent installed in the user’s device. For example, information related to the software installed in the device.

  • LOGIN_USER: When a user login petition is received from the captive portal. This login comes from a registered user.

  • LOGIN_GUEST: When a guest user login petition is received from the captive portal. This login comes from a guest user.

  • REG_USER_ACCEPT: When a registered user login is received from the captive portal.

  • REG_GUEST_REQ: When a guest user approval request from the captive portal is received.

  • REG_GUEST_VALID: When the guest user has validated his email once requested access from the captive portal.

  • REG_GUEST_ACCEPT: When an administrator accepts a guest user request generated from the captive portal

  • REG_GUEST_DENY: When an administrator denies a guest user request generated from the captive portal.

  • REG_GUEST_REEVAL: When it is required to force a policy re-evaluation for a user that is trying to access through the captive portal.

  • TEST: Event exclusively for testing.

  • LOGOUT: When an “end of session” is received.

  • REJECT: When the session is not authenticated because the access credentials are not correct.

  • ERROR: When there is an error in the evaluation of the policy, e.g., if a UDS is not available.

  • NOTIFY_GUEST_REEVAL: When a toggle request is requested from the web interface on a port which has a guest user connected.

1.2.9.1. Events order

These events can occur in any order, but only the last event produced of each type is displayed.

For Example:

The chain of events is as follows:

MAB>IP>PLUGIN

If a new “IP” event is received, the result will be as follows:

MAB>PLUGIN>IP

In the example, the first “IP” event has disappeared. This is because the newest “IP” event, which occurred after the “PLUGIN” event, is considered more relevant now.