> ## Knowledge Base Index
> Fetch the complete knowledge base index at: https://help.trugrid.com/sitemap.xml
> Use this file to discover available pages before exploring further.
> Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash).

# 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.

![](https://storage.crisp.chat/users/helpdesk/website/-/f/4/7/3/f473d72e7d7c5000/image_1x59xdj.png)
### 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](https://help.trugrid.com/en/article/how-to-configure-trugrid-securerdp-for-hybrid-authentication-aoclwe/).

### 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](https://help.trugrid.com/en/article/using-ad-upn-aliases-1lke09e/).
* 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.

![](https://storage.crisp.chat/users/helpdesk/website/-/f/4/7/3/f473d72e7d7c5000/image_cju1lm.png)

### 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](https://help.trugrid.com/en/article/utilizing-sentry-and-secureconnect-brokering-for-accessing-the-same-machine-1b5yhhd/).

### 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.

![](https://storage.crisp.chat/users/helpdesk/website/-/f/4/7/3/f473d72e7d7c5000/image_1iv1e9c.png)

### 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.](https://help.trugrid.com/en/article/trugrid-securerdp-trugrid-ad-admin-federation-sso-9hdrhm/)


### 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](https://help.trugrid.com/en/article/how-to-support-non-ad-environments-1x3yqw4/) and [How to setup the SecureConnect Agent for non-AD computers](https://help.trugrid.com/en/article/how-to-setup-the-secureconnect-agent-for-non-ad-computers-3xq7eq/).

## 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 |

## Related Articles

* [Utilizing Sentry and SecureConnect brokering for accessing the same machine](https://help.trugrid.com/en/article/utilizing-sentry-and-secureconnect-brokering-for-accessing-the-same-machine-1b5yhhd/)
* [How to configure TruGrid SecureRDP for Hybrid Authentication](https://help.trugrid.com/en/article/how-to-configure-trugrid-securerdp-for-hybrid-authentication-aoclwe/)
* [TruGrid SecureRDP - Directory Services Integration and Sizing Requirements](https://help.trugrid.com/en/article/trugrid-securerdp-directory-services-integration-sizing-requirements-1kvkcz2/)
* [How to Configure TruGrid SecureRDP to Authenticate against On-Premise AD](https://help.trugrid.com/en/article/how-to-configure-trugrid-securerdp-to-authenticate-against-on-premise-ad-1of2etj/)
* [How to setup the SecureConnect Agent for non-AD computers](https://help.trugrid.com/en/article/how-to-setup-the-secureconnect-agent-for-non-ad-computers-3xq7eq/)
* [How to support non-AD environments](https://help.trugrid.com/en/article/how-to-support-non-ad-environments-1x3yqw4/)
* [Silent and Mass Installation for TruGrid SecureConnect](https://help.trugrid.com/en/article/silent-and-mass-installation-for-trugrid-secureconnect-1y78um6/)
* [Using AD UPN Aliases](https://help.trugrid.com/en/article/using-ad-upn-aliases-1lke09e/)
* [Best Practices Guide for TruGrid Secure RDP](https://help.trugrid.com/en/article/best-practices-guide-for-trugrid-secure-rdp-zrf7lc/)