Users and devices

From usernames to people

VerOps knows that CORP\jsmith has been using a particular laptop. That is useful for reassignment and license counting, but it is not what most people want to read. Directory enrichment closes the gap: it turns that string into Jane Smith, Finance, reports to R. Patel, entirely server-side, without touching a single endpoint.

User↔device associations

With the users collection module on, agents report the current user and the logged-in users of each machine — Terminal Services sessions on Windows, who on Linux, and RDP/SSH sessions on servers. VerOps keeps these as historical associations rather than a single "assigned to" field:

• each association records the username, its domain, and when it was first and last seen on that machine;
• a machine that several people use over time accumulates several associations, so you can see who has actually been on it, not just who is on it now;
• the current user is surfaced separately on the Hosts table and the asset detail page.

These associations are what per_user license consumption counts, using a trailing 90-day window — see Licenses and compliance.

Privacy by design: VerOps records that an account was signed in to a machine and when. It never collects keystrokes, screenshots, browsing history, message content or the contents of personal files, on any platform, under any policy setting.

Directory enrichment

Configure it under Inventory → Policy → Directory. Two providers ship today, and both feed the same pipeline — matching, storage and display cannot tell them apart.

Microsoft Entra ID (app-only)

The Entra provider reads your directory through Microsoft Graph using the client-credentials flow — an application identity, not a signed-in user, so nothing depends on a person's session. What it needs from you:

Requirement	Detail
Tenant ID	Your Entra directory (tenant) ID.
Client ID	The application (client) ID of an app registration you create for VerOps.
Client secret	A secret on that app registration. Stored encrypted, write-only — see below.
Permission	User.Read.All as an application permission (not delegated), with admin consent granted. This is the single most common setup mistake.

A sync fetches your users in one paged listing and reads each person's manager along the way, so a directory of any size costs one traversal rather than a call per user. If your tenant refuses the manager expansion, the sync retries without it and degrades to "no manager" instead of failing outright. If the application permission or its admin consent is missing, the sync fails with an explicit message telling you exactly that rather than a bare 403.

The provider is read-only by contract. VerOps never writes anything back to Entra — no group membership, no attributes, no device objects.

CSV fallback

If you cannot or will not issue Graph credentials, upload a CSV instead. It is credential-free and produces identical enrichment to a live sync given equivalent data. Columns are auto-mapped from a wide alias list, so most exports work untouched:

userPrincipalName,displayName,department,jobTitle,manager,accountEnabled
jane.smith@corp.com,Jane Smith,Finance,Financial Controller,r.patel@corp.com,true
r.patel@corp.com,R. Patel,Finance,Finance Director,,true

Headers such as UPN, Email Address, Name, Full Name, Dept, Division and Reports To all resolve to the right field. The parser is the same RFC-4180 parser used by asset import, so quoting, embedded commas and newlines behave consistently everywhere.

How matching works — and when it refuses

After every sync, and whenever a new association appears, VerOps tries to link each observed username to a directory person. It works in strict precedence and never guesses:

Order	Rule	Result
1	The username is an exact UPN match.	Linked automatically.
2	The username is DOMAIN\sam, the domain maps to a verified directory domain, and the local part resolves to exactly one person in that domain.	Linked automatically.
3	Two or more plausible people remain after the domain narrowing.	Sent to review — never auto-linked.
4	A bare account name with no domain at all.	Sent to review, even when exactly one candidate exists — there is no domain to verify against, and linking on a local part alone would be a guess.
5	No plausible candidate at all.	Nothing is queued. "Unknown" and "ambiguous" are different states — see the note below.

Verified domains are derived from the UPN suffixes actually present in your synced directory, plus an optional domain map you maintain for cases the convention cannot cover. A short NetBIOS name and its DNS domain are matched conventionally (CORP ↔ corp.com); anything less obvious goes in the map.

Why service accounts do not flood the queue: a username with zero plausible candidates produces no review item at all. Without this, every NT AUTHORITY\SYSTEM and svc_backup on your estate would land in the queue as work no human could ever action. Ambiguity requires at least one real candidate.

The review queue

Ambiguous matches appear as a pending list on the Directory card, each showing the observed username and its candidate people. Confirm one, or reject the item. Two guarantees apply:

• a decision you make — confirmed or rejected — is never re-decided by a later sync;
• confirming also works as a manual link for a username the matcher found no candidate for, such as a contractor whose account name bears no relation to their UPN.

Sync behaviour

• Scheduled nightly, plus Sync now on demand. Organizations using the CSV provider are skipped by the schedule, since their data arrives by upload.
• Idempotent. A second sync of an unchanged directory produces zero link changes and zero row churn — user records and links are both compared before anything is written.
• Leavers are soft-deleted. A person who stops appearing in the directory is marked gone rather than erased, so their historical link keeps resolving on the machines they used.
• Disabling is reversible. Turning the configuration off stops enrichment from being displayed but retains every link. Re-enable and the names come straight back.

Where enrichment appears

Once a username is linked, the Hosts table's User column and the asset detail page's Users tab render the person's display name, with department, job title and manager available on hover. An unmatched username renders exactly as it always did — enrichment is additive and never hides the raw value.

Secrets never leave the server. The Entra client secret is encrypted at rest and is never returned by any API response — reads expose only a "configured" boolean — and never written to a log line. Directory credentials live in server-side configuration only; no credential is ever placed on an endpoint or in an agent's configuration.