Active Directory follow — scenarios and conflicts
What Active Directory follow does and does not inherit, how multi-reader merges resolve, how tags interact with the OU tree, and why portal sign-in stays on SSO/SCIM.
Active Directory follow — scenarios and conflicts
Operators coming from other endpoint or identity products often ask how Trustity “inherits” from Active Directory, what wins when two sources disagree, and whether the same directory connection can sign people into the Cloud Portal.
Short model first:
| Layer | Source of truth | Inherits from AD OUs? |
|---|---|---|
| Device tree browse | Merged directory snapshots (OUs / computers) | Tree shape only — not policy |
| Who gets a module | Tags → profiles → seats on the enrolled station | No |
| FileGuard “who may open” | Signed-in user / groups on the station (including AD groups when synced) | Group membership, not OU path |
| Portal sign-in | Password+MFA and/or SSO; membership via invite or SCIM | No — not the directory-read bind |
Setup steps: Follow Active Directory for devices and policy. Seats and tags: Tags, profiles, and module seats.
There is no GPO-style OU inheritance
Putting a computer in OU=Finance does not assign VisionX, FileGuard, or any other module. The OU tree is inventory and browsing. Module delivery still requires a tag bound to a profile, under your seat caps.
If another product applied “Finance OU → Finance policy pack,” map that habit here as: create a Finance tag, bind it to a Finance profile, assign that tag to the stations (or bulk-tag from a folder). The AD OU is a visual cue, not an automatic assigner.
Manual folders vs Active Directory tree
- Device tree = Manual: you browse portal folders. Folders organize and bulk-tag; they do not set module policy by themselves.
- Device tree = Active Directory: you browse the OU tree. Manual folders are not deleted; they are simply not the browse surface until you switch back.
- Switching modes does not re-tag stations and does not move directory objects.
Multi-reader merges (two stations disagree)
Several Windows readers may upload snapshots. The portal merges by directory object_guid and refreshes last_seen_at.
Typical outcomes:
| Situation | What happens |
|---|---|
| Reader A and B both see the same computer | One inventory row; last successful sighting wins the freshness stamp |
| Reader A is briefly offline | Other readers keep the tree fresh |
| One reader returns a partial / failing upload | A sync-run error is recorded; a later successful upload from any reader restores confidence |
| Object vanishes from every fresh reader for ~6 hours (multi-reader orgs) | Treated as removed from the directory (notice); the enrolled TAO station is not auto-deleted |
| Snapshot hits size caps | Marked truncated — treat the tree as incomplete |
Hostname matching to an enrolled agent uses the first label of DNS hostname / CN. Renames in AD can delay or break the Managed-by-TAO link until the next successful match; the agent enrollment itself is unchanged.
Tags, seats, and the directory tree
| Conflict people expect | Trustity behavior |
|---|---|
| “Finance OU should imply Finance tag” | It does not. Assign the tag explicitly (or via a portal folder bulk action). |
| Station in two tags for the same module | One tag binds to one profile per design; keep one clear tag per module profile and avoid duplicate module tags on the same station. |
| More stations tagged than seats | Portal blocks over-assignment. |
| Seats unset for a module | Entitled stations can still receive the organization Default for that module (legacy-friendly); new packages should always set seats. |
| AD says Disabled, agent still enrolled | Tree shows Disabled; the station can remain Online in the fleet until you remove or reimage it. |
| AD object removed, agent still checking in | Notice on the AD panel; station stays until you remove it from Managed devices. |
FileGuard audiences vs module seats
- Seat / tag decides whether the FileGuard module runs on that PC.
- Audience (“who may open”) uses the signed-in user’s groups. Synced AD groups appear alongside groups observed on stations.
- A user in an AD allow-group still cannot use FileGuard controls on a PC that was never tagged for FileGuard.
Policy version drift
Each enrolled agent reports a policy version. After you change Security Policies, online agents pull a higher version. A station that was powered off or whose service was stopped can stay on an older version until the next successful policy pull — the fleet list highlights that lag. Directory sync and policy pull are independent cycles.
Portal sign-in is not directory read
The LDAPS URL / bind account under Device tree exists so domain-joined Agent One readers can inventory the directory on the customer network. The cloud does not dial your DC for that read.
Cloud Portal sign-in stays on:
- Password + MFA (and break-glass), and/or
- SSO (Entra ID, Okta, …) with optional SCIM for membership lifecycle.
That is intentional:
- Interactive portal login needs IdP MFA, Conditional Access, and session revocation — strengths of the customer IdP, not of a read-only directory bind.
- Reusing the inventory bind account for portal authentication would widen privilege and couple two different trust jobs.
- Most enterprises already sync on-prem AD into Entra/Okta; SSO/SCIM is how those same people reach SaaS portals.
Directory follow and SSO can run together: AD for computers/groups inventory, SSO/SCIM for people who operate the portal. See SSO and SCIM enterprise identity.