Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.velatir.com/llms.txt

Use this file to discover all available pages before exploring further.

​
What this does

Adds the signed-in user’s directory context (department, office, OU hierarchy, group memberships) to every trace the Velatir browser extension sends. Velatir uses this to route traces to the correct workspace, surface department-level analytics, and apply department-specific policies. Some customers route on office (geographic structure) rather than department; both are sent so either works. Works with three identity setups without configuration:
  • On-premise Active Directory
  • Microsoft Entra ID (Azure AD)
  • Hybrid (AD synchronised to Entra)
End users see no prompts and no UI. The full setup is one admin click in Entra, a quick verification on one machine, and an MSI rollout. Open this URL as an Entra administrator in your tenant: 
https://login.microsoftonline.com/organizations/v2.0/adminconsent?client_id=ddddc2f1-9b3e-4ca2-99bf-99cbae699402&scope=https://graph.microsoft.com/User.Read
Microsoft shows a consent dialog with:
  • App: Velatir LDAP host
  • Publisher: ldap.velatir.com
  • Permission: Sign in and read user profile (User.Read only)
Tick Consent on behalf of your organisation and click Accept. Velatir’s app now appears in your tenant under Enterprise applications → Velatir LDAP host, where you can review the permission, see sign-in activity, or revoke at any time.
For pure on-premise Active Directory deployments (no Entra ID), you can skip this step. The host will read from AD directly. For hybrid deployments, do this step anyway so the host has a fallback when users are working off-VPN.

​
Step 2 — Verify on one machine

Before rolling out to the fleet, confirm the host returns the right data on a representative employee machine. Download the test bundle: 
https://cdn.velatir.com/velatir-ldap-host-signed.zip
Extract it. You’ll find:
  • velatir-ldap-host-x64.exe — for x64 Windows (most machines)
  • velatir-ldap-host-arm64.exe — for ARM64 Windows
On a typical employee laptop signed in to your domain or Entra, open PowerShell and run: 
.\velatir-ldap-host-x64.exe --dry-run
A successful run prints JSON like: 
{
  "ok": true,
  "source": "ad",
  "ldap": {
    "department": "Engineering",
    "office": "Copenhagen HQ",
    "ou": ["Product", "Engineering"],
    "groups": [
      { "key": "g_a3f12c", "ou": ["Product", "Engineering"] }
    ]
  }
}
  • source: "ad" — on-premise Active Directory query succeeded
  • source: "entra" — Microsoft Entra ID query succeeded
  • department should match the user’s actual department in your directory
  • office should match the user’s “Office” or “Office location” field. Either field may be empty if your directory doesn’t populate it; the host returns whichever ones are present.
If ok is false, the embedded reason and environment fields describe what is missing:
ReasonFix
appearsDomainJoined: false and a WAM errorRun on a machine signed in to your domain or Entra, not a local Windows account
”admin has not consented”Run step 1
Anything elseForward the JSON output to Velatir support
No data leaves the machine during --dry-run. The tool prints to stdout and exits.

​
Step 3 — Roll out via MSI

The directory-context host ships inside the same MSI you use for the browser extension. Add ENABLE_LDAP_HOST=1 to enable it. Download the installer: 
https://cdn.velatir.com/VelatirExtension-x64.msi
Deploy with: 
msiexec /i VelatirExtension-x64.msi ENABLE_LDAP_HOST=1 API_TOKEN=vltr_yourApiTokenHere ORGANIZATION_NAME="Your Organization" /qn
For ARM64 Windows fleets, use VelatirExtension-arm64.msi instead.
The MSI installs the host EXE under C:\Program Files\Velatir\, registers it with Chrome, Edge, and Firefox as a native messaging host, and pre-warms it for first use. After deployment, every trace the extension sends from that machine automatically carries the user’s directory context. See Browser Extension - Enterprise Deployment for the full MDM-specific commands for Intune, SCCM, and Jamf.

​
What gets sent — and what does not

Four attributes, all in derived form:
  • department — the primary grouping field, sent as-is.
  • office — the user’s “Office” / “Office location” field (AD physicalDeliveryOfficeName, Entra officeLocation), sent as-is. Useful when organisational structure is geographic rather than functional.
  • ou — OU= components parsed from the user’s distinguishedName. CN= and DC= are dropped.
  • groups — for each group the user belongs to: the OU path plus an opaque key derived from a SHA-256 hash. Group CN= values are never sent.
The host explicitly never reads or sends: mail, telephoneNumber, mobile, jpegPhoto, thumbnailPhoto, sIDHistory, any msDS-* attribute, any msExch* attribute. The allowlist is enforced both at the directory query (only the four attributes above are requested over the wire) and in code. When the host cannot return data (machine not joined to any directory, AD unreachable, no Entra account on the box, Conditional Access blocking the app, etc.), it returns an “unavailable” response and the browser extension sends the trace without directory context.

Browser Extension - Enterprise Deployment

Full MDM-specific deployment guides for Intune, SCCM, and Jamf

Browser Extension

General extension features and manual installation