Events

A device can appear listed in openNAC through different sources which are 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 with 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 concentrator that operates with openNAC.

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

  • IP: 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 previous event, but instead of identifying the device by its MAC, it does it using the connection’s name, the network device stablishing 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 which was obtained when a device accessed the captive portal. This event can come from a wide range of source, such as the sensor, the captive portal, etc.

  • AGENT: information is received from the openNAC’s agent which is 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. Usually the Agent detects the lock. This “lock” information is then added. When the user is “unlocked” we will receive a “USERIN”.

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

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

  • 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 is done as there is no need to apply this new petition as old petition has not been executed yet.

  • QRNT: The device has been placed in quarantine.

  • DQRNT: The device has been removed from quarantine.

  • INV_AGENT: detailed information is received from the openNAC’s agent (which is installed in the user’s device). For example, information related to the software installed in the device.

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

  • LOGIN_GUEST: 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 requiered to force a policy re-evaluation for a user that is trying to acces through the captive portal.

  • TEST: event exclusively for testing

  • LOGOUT: when an “end of session” is received

  • REJECT: when the session is not authenticated correctly because the access credentials are not correct

  • ERROR: when there is an error in the evaluation of the policy, for example, that a UDS is not available.

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

Events order

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

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

As it can be seen, the first “IP” event has disappeared. This is because the newest “IP” event that has occurred after the “PLUGIN” event is more relevant now.