TruGrid SecureRDP - How TruGrid Fits Different Active Directory Topologies

Overview


TruGrid can be deployed into almost any Windows identity topology, but the component you use and the login experience your users get depend entirely on where the user account lives relative to the machine they are connecting to.


This article explains the three topologies that come up most often, what login experience each one produces, and which TruGrid component does the work. It is a conceptual guide rather than a step by step install procedure. Each section links to the setup articles that cover the mechanics.


If you take one thing away, take this: TruGrid brokering is scoped by domain, not by forest.


The three components


TruGrid Sentry


Sentry runs on a domain-joined Windows Server and brokers RDP to AD-joined hosts. It provides the SSO experience: on Sentry-brokered machines, TruGrid uses the login username to connect to the target, so the user is not prompted for credentials.


One Sentry serves one Active Directory domain. This is the single most important constraint in this article. Two Sentries per domain are recommended for redundancy.


TruGrid Secure Connect


Secure Connect is an agent installed directly on the target machine. It works on AD-joined, Entra-joined, and standalone Windows computers, and it does not care which domain or forest the machine belongs to.


Secure Connect does not provide the SSO experience. Users are prompted for the credentials of the machine they are connecting to, and may tick REMEMBER ME to shorten later logins. That prompt is a feature, not a shortcoming, and Scenario 2 below depends on it.


Scenario 1 - Multiple domains inside one forest


A single Active Directory forest containing a forest root plus child domains or additional trees. Domains inside a forest trust each other automatically. You do not create anything.


How to deploy it


The default and recommended model is one TruGrid domain registration and one Sentry deployment per Active Directory domain. Each Sentry brokers the hosts in its own domain, and each domain appears in TruGrid as its own entity. Two Sentries per domain for redundancy.


Widening a single Sentry across the forest


For smaller environments where a Sentry per domain is more infrastructure than the estate justifies, a single Sentry can be told to enumerate additional domains in the same forest.


Beginning with TruGrid Sentry 4.3.0.0, on each server running Sentry:

  1. Open the registry and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\TruGrid\Sentry
  2. Add a DomainsIncludedInAdSearch entry with a STRING value
  3. Set it to * for all domains, or to specific domains separated by semicolons with no spaces


The scope of this setting is domains within one Active Directory forest. Full configuration detail is in How to configure TruGrid SecureRDP for Hybrid Authentication.


Login experience


Full SSO. Users authenticate to TruGrid and their session opens without a credential prompt, because Sentry is brokering hosts within a directory it can read.


Things to watch


  • UPN suffixes must line up with the domain validated in TruGrid. If your internal suffix differs from your validated external domain, add an alternate UPN suffix. Multiple suffixes on one TruGrid domain require a UPN alias, which TruGrid configures on request. See Using AD UPN Aliases.
  • Sentry servers and the RDP hosts they broker must be on the same high speed local network. Brokering across a WAN or site to site VPN introduces latency. Where that is unavoidable, use Secure Connect on the remote hosts instead.


Scenario 2 - Separate forests joined by a forest trust


Two distinct forests with a trust between them. The user account lives in one forest, the machine they need lives in the other. A common shape for acquisitions, subsidiaries, and MSPs who have built a genuine trust relationship with a client.



Why Sentry alone does not solve this


A Sentry in the primary forest cannot broker hosts in the trusted forest. One Sentry serves one domain, and the presence of a trust does not change that. This is a TruGrid brokering boundary, not a Windows authentication boundary.


Secure Connect has no such limit. Because the agent sits on the machine itself, it can publish hosts from any number of domains and forests into TruGrid.


The pattern


Install the Secure Connect agent on the target hosts in the far forest and publish them into TruGrid. Then:

  1. The user signs in to the TruGrid Connector or Web Portal with their own primary forest identity
  2. They launch the Secure Connect published host in the trusted forest
  3. Because Secure Connect provides no SSO, Windows prompts for credentials
  4. The user types their own primary forest credentials
  5. The forest trust allows the target forest to validate them, and the session opens
  6. REMEMBER ME shortens this for subsequent connections


The credential prompt is the whole point. It is the entry point where a trusted cross-forest identity can be supplied, which SSO would otherwise bypass.


This same Sentry plus Secure Connect combination can be applied to a single machine so that it appears twice in the user's workspace, once brokered each way. See Utilizing Sentry and SecureConnect brokering for accessing the same machine.


Trust direction


A two way trust is recommended and is the simplest to reason about. A one way trust also works, provided the direction is correct: the forest containing the resource must trust the forest containing the user. Getting this backwards produces authentication failures that look like TruGrid problems but are not.


Host side permissions


Windows still enforces its own rules. The target host must grant the trusted principal RDP rights, either directly or through a trusted group nested into the local Remote Desktop Users group. If the trusted user has no RDP rights on the host, the session is denied regardless of TruGrid configuration.


Login experience


Credential prompt on first connection, then optionally remembered. Not SSO. If you need SSO across separate domains without a trust, that is Scenario 3.


Scenario 3 - Separate domains with no trust: Active Directory Federation


Two unrelated domains with no trust between them. The classic MSP shape: your technicians live in your own domain, your customers each have their own, and no one is building forest trusts across client boundaries.



How it works


TruGrid provisions a shadow account, prefixed with TG-, inside the customer domain's Active Directory and manages that account's password itself. Because the authenticating account already resides in the customer domain, there is no cross-forest authentication to validate and therefore no trust to establish.


The technician signs in with their own primary domain identity, approves a push notification in the TruGrid Authenticator app, and the session opens with no credential prompt.


Requirements worth knowing up front


  • The TruGrid service account in the customer domain needs delegated rights to create and delete users and manage group membership. Without them, shadow account provisioning fails.
  • TruGrid Authenticator is a hard requirement. Other MFA methods authenticate the TruGrid login but fall back to a credential prompt instead of the push.
  • Assignments are per individual user. Group-based assignment is not supported.


Full setup is described in the Active Directory Federation article.



Login experience


Full SSO into the customer domain, gated by an Authenticator push approval.


Hybrid and Entra ID


A hybrid environment is still an on-premises Active Directory environment. If your directory is synchronised to Entra ID, Sentry integration and trust relationships behave the same way they would without the sync, and the scenarios above still apply. Synchronisation changes where identities are also published, not how the on-premises forest authenticates.


For environments with no on-premises Active Directory, Secure Connect is the component to use. See How to support non-AD environments and How to setup the SecureConnect Agent for non-AD computers.


Summary


Topology

Component

Trust needed

Login experience

One domain

Sentry

Not applicable

SSO

Multiple domains, one forest

Sentry per domain, or one Sentry with DomainsIncludedInAdSearch

Automatic within the forest

SSO

Separate forests

Secure Connect on far-forest hosts

Forest trust required

Credential prompt, remembered after first use

Separate domains, no trust

Active Directory Federation with shadow accounts

None

SSO with Authenticator push

No on-premises AD

Secure Connect

None

Credential prompt, remembered after first use



Updated on: 18/08/2026

Was this article helpful?

Share your feedback

Cancel

Thank you!