ClearPass Access Tracker: what to read there, and when a request does not show up

Notes from reading documentation, not results from testing on a live system. Main source: HPE’s ClearPass 6.8 Deployment Guide. Each point carries a page citation at the end; anything that could not be verified is marked.

Access Tracker (Monitoring → Live Monitoring → Access Tracker) lists every authentication request and how it was handled. It is the first place to look when something breaks — and also something to budget disk space for, because Policy Manager records a lot of data for each transaction¹.

Two traps to know:

• No record ≠ rejected by policy. The request never reached the policy framework — wrong shared secret or wrong device IP. Go to Event Viewer, don’t go editing policy¹.
• In a cluster, logs are not replicated. A record lives only on the node that handled the request; open the wrong node and it looks as if the request never arrived¹.

Components

What to read here

• Each record is one transaction: the attributes received, the policy applied, the result returned.
• DataFilter is the entity used to filter records in Access Tracker as well as syslog messages¹.

When a request does not show up in Access Tracker

This is the most important diagnostic situation: a missing request means it never made it into the policy framework, not that policy rejected it. The Deployment Guide points to two things to check¹:

1. The shared secret between the mobility controller and the Network Access Device configuration in Policy Manager. A wrong shared secret shows up under Monitoring → Event Viewer.
2. The controller’s IP address as configured in Policy Manager. Any mismatch and Event Viewer reports an ERROR/WARN along the lines of “received an authentication request from an unknown IP”.

In other words: empty Access Tracker, go to Event Viewer — don’t go editing policy.

Logs in a cluster

• The log of each authentication request is written only on the node that handled that request, into that node’s own log database. For centralized reporting, use ClearPass Insight¹.

• Access Tracker logs and session logs are NOT replicated between Publisher and Subscriber. Also not replicated: authentication records, accounting records, system events (Event Viewer data) and system monitoring data. Configuration and identity store data are replicated¹.

  The consequence when diagnosing in a cluster: you have to find the node that handled that session. No record on the node you have open does not mean the request never reached ClearPass.

• Cluster file backup sends configuration only by default. To back up Access Tracker logs as well, enable it under Administration → Server Manager → Server Configuration → Cluster-Wide Parameters, Database tab, on the Publisher node¹.

Unverified. The source is the 6.8 Deployment Guide. Menu paths and parameter names may have changed in the current release. I have no source yet that describes the columns, built-in filters or the detail tabs of a record.

Related

• Operating ClearPass from the CLI (appadmin) — system upgrade backs up but does not restore Access Tracker records unless the -w/-l flag is given

Sources

Footnotes

1. ClearPass 6.8 Deployment Guide, PDF pp. 148, 150, 152, 170–172, 215, 317 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸