Skip to content
Thirdlane

Users and Access

Users and Access reports on who signs in, from where, how long they stay, and what they use once they are in. It covers every way into the system - Configuration Manager, the User Portal, Thirdlane Connect on web, desktop and mobile, and the REST API - so the same question can be asked across all of them at once.

Open it from Reports > Users and Access.

Typical questions

  • Who signed in this week, and from which application?
  • Is anyone still using the User Portal now that Connect is deployed?
  • Which features do people actually open, and does that differ between the portal and Connect?
  • Is one address failing to sign in against many accounts?
  • Who changed that setting, and when?

The six sections

Sessions shows sign-ins that succeeded: how many, by how many people, across which surfaces, and how long each lasted. The per-surface averages are the most useful number here, because they differ enormously by design - a desktop Connect client stays open all day, while a portal visit to check voicemail lasts a few minutes.

Logins and Logouts shows every attempt, successful or not, broken down by day, by hour, by authentication method and by surface, with a table of the source addresses that failed most often.

SIP Registrations shows how phones and softphones came and went: registrations, expiries, and devices that became unreachable, with the countries and user agents behind them. See Registration history below for what this section can and cannot tell you.

Feature Usage shows which parts of the product were opened, per day and per person. Counts are aggregated daily rather than stored per request, so this section answers “how much is this used” rather than “what did this person do at 14:32”.

Activity and Change Log shows configuration changes made by administrators - the same data as the Change Log grid, summarized over the report period.

Security Events shows what the automatic checks concluded from all of the above. See Security events below.

How a session is measured

Most sessions never end with a logout. People close a tab or quit the application, and nothing tells the server. Session length is therefore measured from sign-in to the last activity seen, and a logout time is recorded only when one actually happens. The Sessions section shows both, so you can see what proportion of each surface signs out properly.

A session with recent activity and no logout is shown as still active.

Failed and denied attempts

A failure is a sign-in that did not succeed - usually a mistyped password. A denial is different: the credentials were valid, but that account is not permitted on that surface, such as an administrator account reaching a portal-only node. The two are counted separately because they mean different things.

Failed sign-ins to Configuration Manager and the User Portal are reported without a surface, shown as unknown. This is not a gap in the data: those two surfaces are authenticated before the account’s permissions are known, so there is nothing yet to attribute the attempt to. Connect failures do carry their surface, because Connect authenticates through a different path that knows the client.

Repeated failures from one address against many different accounts is the signature of a credential-spray attempt, and the failures-by-address table is what makes it visible. Also see Banned IPs.

Where sign-ins came from

Sessions and sign-in attempts are grouped by country, worked out from the source address. Read this as where the connection came from, not where the person is: an address is a reasonable guide to a country and a poor one to anything smaller.

Country is what the report groups and totals on. A city is shown alongside individual rows where one is known, but it is deliberately never aggregated - address-to-city accuracy is weak in general and much weaker on mobile networks, so a city total would look precise and be wrong.

Sign-ins from private, internal or otherwise unroutable addresses are grouped as Private or internal. That is normal for staff on an office network or behind a VPN, and it is shown rather than hidden so the totals still add up.

The most useful thing on the page is the country breakdown next to the failure counts. Ordinary countries show a handful of failures against a large number of successes. A country showing almost nothing but failures, spread across many different usernames and arriving from only one or two addresses, is an attack rather than a group of people who forgot their passwords.

Locations are filled in by a background task within a few minutes of the sign-in, so a very recent attempt may briefly show no country.

Registration history

The SIP Registrations section is a history of change, not a picture of the present. To see which extensions are registered right now, use Users Status. This section answers a different question: what changed, when, from where, and on what device.

Registration state is sampled every few minutes rather than watched continuously, so a device that registers and drops between two samples will not appear. Steady traffic is normal and expected - phones re-register on a timer, so a healthy system produces a constant baseline of registrations and expiries.

Three things are worth looking at:

  • Devices Seen is a truer inventory than any asset list, because it shows what actually registered rather than what was supposed to be deployed. Unexpected user agents and old firmware both surface here.
  • Busiest Extensions ranks by event count, and the extension at the top is rarely the busiest person. Repeated registration and expiry cycles on one extension almost always mean a flapping device or a NAT timeout that is dropping the binding.
  • Countries on a single extension should normally be one. An extension registering from a country it has never used before is worth a look even when the credentials were valid, since a stolen SIP password produces exactly that pattern.

Security events

The other sections show what happened. This one shows what the system made of it. A set of checks runs every hour over the sign-in and registration history and records anything that looks wrong as a finding.

Findings are grouped by subject rather than listed per event. If one address is working through your account list, that is a single finding whose event count rises while the attempt continues - not a new line every hour. When the activity stops, the finding closes itself and records why, so the Open Findings list stays short enough to be worth reading.

The checks are:

FindingWhat it means
Credential sprayOne address failing against many different accounts. Somebody is working through a list of user names.
Brute force on one accountMany failures against a single account from one or two addresses. Somebody is working through a list of passwords.
New country for a userSomeone signed in from a country they have never used before. Often travel, sometimes not.
New country for an extensionA phone registered from a country it has never used before. Rated higher than the user version, because people travel and desk phones do not.
Registrations droppedFar fewer phones registering than is normal for that organization at this time of day. Frequently a network or power problem rather than an attack, but always worth knowing.
Dormant account usedAn account with no activity for months was used successfully. Usually somebody returning, occasionally an unused account that has been taken over.

Open Findings ignores the report period on purpose. Something still unresolved matters whenever it started, and having it vanish because you changed the date range would be a good way to miss an incident. The lower table respects the period as usual.

A few things to know before acting on a finding:

  • The country checks need history before they say anything. A user or extension must have roughly ten previous events, or two weeks of history, before an unfamiliar country counts as new. A newly created account will not raise this finding no matter where it signs in from.
  • Countries, not cities. Location is compared at country level only. City-level accuracy is poor on mobile networks - often out by more than a hundred kilometres - so a finding is never raised on a move within one country.
  • Automatic sign-ins are excluded from the country checks. Apps refreshing their credentials in the background frequently appear to come from a data centre unrelated to the user, which would otherwise produce a steady trickle of false alarms.
  • A finding is a prompt to look, not a verdict. A genuine trip abroad and a stolen password produce an identical record. What separates them is context this report does not have.
  • The registration check needs a busy baseline. It compares how many phones registered in the last few hours against the same hours on previous days, so it only speaks up where registrations happen regularly and where enough phones are involved for the comparison to mean anything. Somewhere every phone registers once and then stays put for weeks, it will stay quiet - treat it as a useful extra signal rather than your outage alarm.

Findings are not yet sent anywhere - there is no email or webhook on a new finding, and they cannot be acknowledged from this page. Both are planned.

Access

The section is visible to platform administrators and to administrators holding the Users permission. Everyone else sees only the report categories their role allows, so granting reporting access to a contact-center or marketing role does not expose the sign-in audit.

Administrators scoped to organizations see only their own organizations. Sign-ins that belong to no organization - platform administrators, and failed attempts for accounts that do not exist - are visible only to platform administrators.

Retention

Sign-in history and feature usage are kept for separate periods, both configurable under General Settings & Tools > Preferences on the Data Retention tab. Sign-in records default to about twelve months; feature usage defaults to three years.

The two differ on purpose. Sign-in records carry a source address and a browser identity, which are personal data in most jurisdictions and should not be kept longer than there is a reason to. Feature usage is a daily counter with no such content, so it can be kept long enough to show multi-year adoption trends. Old records are removed automatically by the nightly maintenance job.

Best practices

  • Give every administrator their own account. Shared logins make every figure in this report meaningless, and the change log along with it.
  • Check the failures-by-address table after any exposure change, such as opening a new hostname or moving a node.
  • Read Open Findings before the raw sections. It is a short list by design, and it points at the part of the raw data worth reading.
  • Compare surfaces before retiring one. Portal versus Connect usage of the same feature is the evidence for whether anyone would notice.
  • Set retention to match your policy, not to the maximum available.