Configuration

All configuration is done by sending JSON encoded retained message to MQTT topics under`conf/` on localhost. No validation is made on the format nor on the parameters, they will be used as is.

IP Configuration

IP v4

topic:

conf/ipv4

format:
{
  "type":    <string: "none">, // `dhcp`, `static` or `none`. Unknown value is same as `none`
  "address": <ip4>,            // IP address when `type` is `static`
  "mask":    <int>,            // mask when `type` is `static`
  "dns":     <ip4[]: []>,      // List of DNS servers (in case of `dhcp`, will be added to received ones).
}

If no configuration, defaults to dhcp.

IP v6

topic:

conf/ipv6

format:
{
  "type":    <string: "none">, // `autoconf`, `dhcp`, `static` or `none`. Unknown value is same as `none`
  "address": <ip6>,            // IP address when `type` is `static`
  "mask":    <int>,            // mask when `type` is `static`
  "dns":     <ip6[]: []>,      // List of DNS servers. (in case of `dhcp` or `autoconf`, will be added to received ones).
}

If no configuration, defaults to autoconf.

Administrator Configuration

Administrators can connect to the Agent web console to configure its network, like IP addresses, DNS and default gateway.

topic:

conf/administrator

format:

list of administrator definitions

[
  {
      "login":    <string: *Mandatory*>,
      "password": <pbkdf2 encrypted: *Mandatory*>
  }, ...
]

VLAN Configuration

VLANs are identified by the network interface of the agent and the VLAN identifier. ELAN Agent should only be connected once to every VLAN, ie do not connect the same VLAN on 2 different NICs. However, if those vlans are completly separate, it can be connected to 2 vlans with the same identifier on different interfaces.

topic:

conf/vlans

format:

list of vlan definitions:

[
  {
    "id":                        <int>                  // Unique ID for the vlan so it can referenced by other vlans.
    "interface":                 <string: *Mandatory*>, // Nic Name
    "vlan_id":                   <int: 0>,              // Vlan Identifier
    "access_control":            <bool: false>, // Enable access control on that vlan
    "log":                       <bool: false>, // Enable connection logging
    "ids":                       <bool: false>, // Enable IDS on that vlan
    "web_authentication":        <int: null>, // ID of Authentication to use when authenticating users on captive portal
    "guest_access":              <int: null>, // ID of Guest Access to use on this vlan
    "dhcp_passthroughs":         <int[]: []>, // IDs of vlans to which DHCP/IPv6autoconf requests are allowed even if device not allowed to these VLANs
    "dns_passthroughs":          <int[]: []>, // IDs of vlans to which DNS requests are allowed even if device not allowed to these VLANs
    "ndp_passthroughs":          <int[]: []>, // IDs of vlans to which ARP/NDP requests are allowed even if device not allowed to these VLANs
    "mdns_answers_passthroughs": <int[]: []>, // IDs of vlans to which MDNS answers are allowed.
  },
  ...
]

NDP passthroughs always include DHCP and DNS passthroughs. They can be useful if you want to give access to a resource via captive portal authentication as a device needs to resolve IP to MAC to access the service before getting redirected by captive portal. For example when WAN connectivity is not on the same Network as DHCP and DNS.

Authentication Configuration

Authentications can be used by captive portal and 802.1X to authenticate users against existing user databases.

topic:

conf/authentication

format:

list of authentication definitions:

LDAP:User will be authenticated using the following attributes for the password: userPassword, ntPassword or sambaNTPassword.
{
  "id":         <int: *Mandatory*>,        // id that can be used in members of a group.
  "type":       "LDAP",
  "host":       <ip or fqdn: *Mandatory*>, // must match Common Name of Server Certificate if certificates used.
  "port":       <int: 389 or 636>,         // port to connect to. Defaults to 636 if encryption is ssl, 389 otherwise.
  "encryption": <string: "none">,          // ssl, start_tls or none.
  "server_ca":  <string: "">,              // PEM encoded Certificate Authority to check against when encryption is "start_tls" or "ssl". If not provided check, not performed.
  "baseDN":     <string: "">,              // baseDN from which user will be searched.
  "bindDN":     <string: "">,              // User DN used to bind to LDAP for search. No bind if empty.
  "bindPwd":    <string: "">,              // Password of user used to bind to LDAP.
  "userAttr":   <string: *Mandatory*>,     // Attribute against which search for the user authenticating.
  "userFilter": <string: "">,              // LDAP filter used when searching for user. No filtering if empty.
}
Active Directory:
 Authentication will be performed by joining the AD domain. Only one AD is supported.
{
  "id":         <int: *Mandatory*>,    // id that can be used in members of a group.
  "type":       "active-directory",
  "domain":     <string: *Mandatory*>, // domain to join. Should resolvable by agent DNS.
  "adminLogin": <string: null>,        // admin login used to register to domain
  "adminPwd":   <string: null>,        // password of admin.
}
External:Authentication will be made by doing a request via MQTT. Unknown Authentication IDs will be considered external, so you don’t really need to declare them.
{
  "id":   <int: *Mandatory*>, // id that can be used in members of a group.
  "type": <string: external>, // unknown authentication types will be considered external
}
Groups:Authentication will be tried among members of the group, in the order defined. Nested and circular groups are supported. If an authentication has been tried once, it will not be retried, even if it appears in several groups that are members of the group.
{
  "id":      <int: *Mandatory*>, // id that can be used in members of a group.
  "type":    "group",
  "members": <int[]: []>         // list of authentication IDs. If an ID is not present in list of authentication, it will be considered as external.
}

RADIUS Configuration

Radius will support both 802.1X and MAC-authentication. It will accept all incoming request with the correct secret. All network equipments share the same RADIUS secret.

topic:

conf/radius

format:
{
  "default_secret": <string: *Mandatory*>, // Secret used to authenticate RADIUS requests
  "dot1x_authentication": <int>            // authentication id to be used for user during 802.1X requests. Can be a group.
  "cert_chain":           <string>         // PEM encoded Certificate Chain to return to 802.1X client.
  "cert_key":             <string>         // PEM encoded Private key
}

SNMP Configuration

SNMP configuration is used for both SNMP polling and SNMP Trap/Informs. Several credentials can be used, on first poll first one to succeed will be used. SNMPv3 credentials will be tried, then v2c, and finally v1.

topic:

conf/snmp

format:
{
  "credentials": [
    {
      "community":  <string: *Mandatory*>, // Community for SNMP v2c and v1
                                        // or User for SNMPv3 (
                                        //         NoAuth NoPriv if `auth_key` not present,
                                        //      or Auth noPriv if `auth_key` present but not `priv_key`,
                                        //      or Auth Priv if both `auth_key` and `priv_key` present)
      "auth_proto": <string>, // MD5 or SHA
      "auth_key":   <string>, // If present, used for SNMPv3 Auth (NoPriv or Priv if `priv_key` present)
      "priv_proto": <string>, // DES or AES
      "priv_key":   <string>, // If present, used for SNMPv3 Auth Priv
    },
    ...
  ],
  "engine_ids": <string[]: []> // list of Engine IDs used in SNMPv3 Informs. Hex string without leading 0x.
}

Guest Access Configuration

Guest Access Service gives the ability to guest to fill up a form that is then submitted to the guest-request service that can take the necessary actions to allow the guest on the network. The guest-request service is to be implement according to your needs.

topic:

conf/guest-access

format:
[
  {
    "id":     <int>,     // ID that can be used in vlan definitions for `guest_access`.
    "modification_time": // Sent at each Guest Request so we can invalidate authz if guest access has been updated.
    "fields": [          // list of form fields that guest can fill on captive portal to get access
      {
        "id":                  <string: *Mandatory*>, // unique id of field.
        "type":                <string: *Mandatory*>, // `text`, `textarea`, `email`, `date`, `date-time`, `time`.
        "display_name":        <string>,              // Name displayed before the form field.
        "required":            <bool: true>,          // Whether that field must be filled by guest.
        "validation_patterns": <pattern[]: []>,       // if not empty, field should match matches at least one of the patterns (for example `*@my-domain.com` for an email)
      },
      ...
    ],
    "description": <html: "">, // Description that sits above the guest request form.
    "policy":      <html: "">, // User Policy Agreement that is displayed below the guest request form/
  },
  ...
]

Active Authorizations

This is used to tell ELAN agent what are the current active guest access authorization. This can for example be used by your implementation of guest-request service. When an authorization is revoked, republish list of active authorizations without it. Timeouts (till parameter) are taken care automatically, no need to republish the list once timedout.

topic:

conf/guest-access/active-authorizations

format:
[
  {
    "id":             <int>,              // id of the authorization
    "mac":            <mac>,              // device allowed by guest access
    "till":           <UTC ISO8601 date>, // validity of authorization
    "sponsor_login":  <string>,              // Login used to authenticate sponsor.
    "sponsor_authentication_provider":    // id of authentication provider used to authenticate sponsor
  },
  ...
]