Zum Inhalt springen
TARANAC

Discovery & profiling

A MAC address says which device knocked. It does not say what the device is. A NAC policy that should put laptops on one VLAN, printers on another and a robot vacuum on a third needs that second answer, and it needs it without anyone typing it in for every device.

Discovery and profiling is how Taranac gets it. Discovery sources listen to, ask, or look up each device and store what they learn as evidence on the endpoint. Device Profiling reads that evidence with rules and gives the device a name from a tree, such as Any device › Computer › Windows › Laptop. Endpoint groups classify on the name, and the NAC policy decides the VLAN for each group.

One device, four stages: three sources report what they heard, the evidence lands on the endpoint, the profiler walks the tree to Laptop, and a group that classifies on “Computer › Windows and below” puts it on VLAN 20.

Everything in this section lives under NAC → Discovery Sources in the admin UI: DHCP Probe, Web Probe, SNMP, Scanner, Device Profiling and OUI Database.

Key concepts

Section titled “Key concepts”
TermWhat it means
Discovery sourceAnything that reports on a device: the DHCP Probe, the captive portal, the directory, the Scanner, SNMP (including switch neighbour and forwarding tables), the Web Probe, RADIUS sessions and the OUI registry.
EvidenceWhat a source heard or read: a DHCP request list, a vendor class, a browser string, a recorded OS, open ports, an LLDP description. Rules reason about evidence. It is never taken as the answer by itself.
AssertionA value a source states outright rather than hands over as a clue. Today only the Web Probe does this, through its reserved profiling attributes. An assertion outranks anything the rules concluded.
Device profileA node in the profile tree, such as Computer › Windows › Laptop. Each device carries exactly one: the deepest node it qualifies for.
DimensionOne of the four things rules conclude independently: OS family, OS version, device type, manufacturer. A fifth, connection (Wi-Fi or cable), is read from RADIUS sessions rather than concluded.
ConfidenceHow strongly the evidence supports an answer. It is shown as one of three words: confident, likely or a guess.
CollectorA remote Taranac node on a site. It can be a DHCP listening point, run the Scanner, poll SNMP or run a Web Probe, and it reports back over its enrolment.

How it works

Section titled “How it works”

1. Sources report evidence

Section titled “1. Sources report evidence”

Each source has its own page and its own way of getting data. What they have in common: they only record what they saw about a device. The DHCP Probe is passive and never sends a byte. The Scanner sends packets only in the zones where you chose an active method. The directory is read, not written.

The DHCP Probe also never creates an endpoint. A sender chooses its own MAC address and host name, so a packet on the wire is not enough to add a device to your inventory.

2. Evidence stays evidence

Section titled “2. Evidence stays evidence”

Some of what sources learn could also fill fields on the endpoint record, namely the host name and the operating system. What a device says about itself is evidence, not a record. Each field has an owner, and a source may overwrite it only if:

  • nobody owns the field yet, or
  • the source already owns it (a source may always correct its own earlier reading), or
  • the source is trusted at least as much as the current owner. When two sources are trusted equally, the later reading stands.
FieldTrust order (higher overrules lower)
Host nameA person (40) › Directory (30) › Certificate (20) › DHCP (10)
Operating systemA person (40) › Directory (30) › Web Probe (28) › Captive portal (25) › DHCP fingerprint (20) › MAC address (10)

So a guest who edits their browser string cannot rename what your directory knows about a machine, and a device that puts a misleading name in its DHCP request cannot overwrite a name from a certificate. You can change the operating system order on the Device Profiling Settings tab (see Device profiling). The host-name order is fixed.

A DHCP or captive-portal verdict is written into the endpoint’s OS field only when its confidence reaches the minimum confidence on that same Settings tab (50 by default). Below that, it stays a reading on the device card.

3. Device Profiling names the device

Section titled “3. Device Profiling names the device”

Rules read the evidence and conclude values in the four dimensions. Each source gets one vote, not each rule: three rules reading the same DHCP request list are one witness, while a request list, a browser string and a directory record that agree are three. The profiler then walks the profile tree from Any device downwards and stops at the deepest node whose conditions hold with enough confidence. The device card says why it stopped there.

This is covered in full on Device profiling. The rules themselves are covered on Profiling rules.

4. Groups and policy act on the name

Section titled “4. Groups and policy act on the name”

An endpoint group can classify on a Device profile condition: a node exactly, or a node together with everything under it. It can also classify on a Web Probe condition. The NAC policy then matches on the group. When a device’s name changes, its group membership is checked again, and only for the devices whose name actually moved.

A new name reaches policy within seconds. Every source marks the devices it heard about in the same transaction that stores the evidence, and one queue, drained on the cluster leader, works out their names again.

Collectors as listening and scanning points

Section titled “Collectors as listening and scanning points”

A single core cannot hear every segment. A site collector (registered under Settings → System → Collectors, see Collectors) extends discovery to where the devices are:

  • DHCP Probe: a collector can be a listening point for relayed DHCP. This is off by default and switched on per machine.
  • Scanner: runs on a collector, in zones built from that collector’s interfaces and VLANs.
  • SNMP: a profile names who polls, either the core or a specific collector. There is no silent fallback from one to the other.
  • Web Probe: a probe can run from the core or from a collector.

Which source do I need?

Section titled “Which source do I need?”
You want to know…UseWhat it gives the profiler
What any DHCP client runs, without touching itDHCP Probe (add an ip helper-address pointing at Taranac)Request list, vendor class, host name, domain name, client signature, and the switch port from option 82
The exact OS and version of guest and BYOD devicesCaptive portalThe browser User-Agent and, from Chromium browsers, Client Hints (real platform version, model)
The OS of domain-joined machinesDirectory (LDAP / AD)The operating system recorded on the computer object, the strongest signal there is
What silent devices are: printers, cameras, servers, anything that never opens a browserScanner on a collectorOpen ports and banners, nmap’s OS guess, UPnP, mDNS, NetBIOS, LLDP/CDP
Which switch port a device is on, and what phones and APs say about themselvesSNMPNeighbour (LLDP/CDP) and forwarding tables, and the sysObjectID of polled devices
What your MDM, inventory or antivirus console knowsWeb ProbeAnything your script answers, plus direct assertions of OS family, version, device type and manufacturer
Laptop or desktopRADIUS sessions (802.1X / MAB with accounting)NAS-Port-Type: wireless or wired
Who made the network cardOUI databaseThe manufacturer, from the longest matching MAC prefix

Most estates need two or three sources. The DHCP Probe covers almost everything that takes an address. The directory covers managed Windows, macOS and Linux machines. The Scanner covers devices that are quiet on DHCP and have no directory record.

In this section

Section titled “In this section”
Section titled “Related”
  • Endpoints: endpoint groups and classification rules, including the Device profile condition.
  • NAC policy: how a group becomes a VLAN.
  • Captive portal: where the browser signals come from.