> ## 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 - Reduced Privilege Sentry setup

### Overview


Production Sentry version, by default, creates a Service Account that is automatically promoted to Domain Administrator. This build does not have this requirement and allows organizations to use the least privileged principle as well as to fully manage the Sentry service account. 

This is a two-part setup and both parts are mandatory:
1. The special Sentry, running as a suitably permissioned service account.
2. An AD delegation (`dsacls`) that grants that service account the Reset Password right over the target users.

||| Skip part two and the Sentry installs cleanly, the service starts, everything looks healthy, and password resets fail with Access Denied. The delegation is not optional and it is not automatic.


### Where it runs

| This build can be obtained by contacting TruGrid support via chat or emailing help@trugrid.com . 

* The special Sentry runs on the **Sentry server**.
* **It must not be installed on a Domain Controller** as there is no way to make the service account a local administrator on a DC. 

### Required local administrator rights

The Sentry service account requires **local administrator** rights in two places:
| Server | Requirement | Reason |
| Sentry server | Local administrator | Runs the Sentry service and its reset pipeline |
| Each RemoteApp server | Local administrator | Required for RemoteApp session and reset operations against those hosts |

Grant local admin on every RemoteApp server in scope, not just one. A RemoteApp host the account is not admin on will not behave correctly.

### Installing and setting the service logon


The service account can be **fully managed by the client** - client naming conventions, client password policy, client-driven password rotation. TruGrid does not dictate the account name or own its credentials. Respect whatever the client already runs.

### Process
1. **Install** the Sentry on the Sentry server using the build from Support.
2. **Stop** both the "TruGrid Sentry Health Monitor" and "TruGrid Sentry" services. 
3. **Change the service "Log On As" account** to the Service account

![](https://storage.crisp.chat/users/helpdesk/website/-/f/4/7/3/f473d72e7d7c5000/image_wv1p2k.png)
4. **Start the services again.**

### Password rotation


Because the account is managed, when you rotate the password you **must also update the service logon** with the new password (step 3) and restart the services (step 4). A rotated password that is not updated on the service will stop the Sentry at next restart. 

### Active Directory delegation (dsacls) - the step that makes resets work


Everything above gets the Sentry running under the right account. None of it grants that account the ability to reset a single password. That right is granted separately, in Active Directory, with `dsacls`. **This is the final and load-bearing step of the setup.**

### What is being granted

You can grant one specific extended right: **Reset Password**. This is the administrative override that sets a new password without knowing the old one. It is distinct from *Change Password* (which requires the old password and is for end users). The service account needs Reset, not Change.

### Where it is scoped

Scope the right on the **Organizational Unit where the target user objects physically reside** - not on a security group.

This is the single most common mistake, so it is worth being explicit: an ACE placed on a security group grants control **over the group object itself** (its membership, its attributes). It grants **nothing** over the user accounts that are members of that group. AD permissions inherit down the OU tree by object containment, not by group membership. A user is a child of its OU, never a child of a group it belongs to.
* Correct: scope on the OU (e.g. `OU=TG_Users,...`). Every user in the OU inherits the right, and new users dropped into the OU are covered automatically.
* Wrong: scope on a group (e.g. `CN=TG-USERS,...`). The command succeeds, reports success, and grants zero reset ability. Silent no-op.

A group *is* valid in the other slot - as the account receiving the right (the grantee), instead of a single service account, if you prefer to manage the delegation by membership. But the **target** must be the OU.

### The command

cmd
```
dsacls "OU=TG_Users,DC=example,DC=com" /I:S /G "DOMAIN\svc-account:CA;Reset Password;user"
```

Flag breakdown:
| Element | Meaning |
| `/I:S` | Inherit to **child objects only** - the right lands on user objects inside the OU, not on the OU object itself |
| `/G` | Grant |
| `CA` | Control Access - the class of right that Reset Password belongs to (an extended right, not a simple property write) |
| `Reset Password` | The extended right being granted |
| `;user` | Scope to **user** objects only, not computers, contacts, or anything else parked in the OU |

For localized (non-English) domains, the display name `Reset Password` may not resolve. Use the right's GUID instead - it is identical on every domain worldwide:

cmd
```
dsacls "OU=TG_Users,DC=example,DC=com" /I:S /G "DOMAIN\svc-account:CA;00299570-246d-11d0-a768-00aa006e0529;user"
```

### Verify it landed

Do not trust that it worked because dsacls did not error. Read it back against a real user in the OU:

cmd
```
dsacls "CN=SomeUser,OU=TG_Users,DC=example,DC=com" | findstr /I "Reset"
```

Expected: a line showing the service account with **Reset Password** / **CONTROL ACCESS**.

### Prove it end to end

Test the reset from a **session running as the service account**, not from your own admin session. Testing as yourself proves nothing, because you could reset the password regardless of the delegation.

powershell
```python
Set-ADAccountPassword -Identity someuser -Reset -NewPassword (ConvertTo-SecureString "TempPass!2026" -AsPlainText -Force)
```

Success confirms the delegation is live and correctly scoped.

## Notes and known gotchas

**AdminSDHolder / adminCount will block resets on affected accounts.** If a target user is (or ever was) a member of a protected group - Domain Admins, Enterprise Admins, Account Operators, Administrators, Backup Operators, Server Operators, Print Operators, Schema Admins, Read-only Domain Controllers, Replicator - the SDProp process stamps `adminCount=1` on the account and **disables ACL inheritance** on that object. 

Your OU-scoped delegation cannot reach it, and the reset fails with Access Denied even though the ACE is present on the OU.

* This is a symptom of *inheritance being severed on the object*, not a bad delegation.
* On accounts still in a protected group, this is correct and by design - do not fight it, and do not keep privileged accounts in a delegated OU in the first place.
* On accounts that were *formerly* protected (a common setup-time scar - test accounts dumped into Domain Admins and later removed), the flag and the broken inheritance persist forever because AD never reverses them. These need a manual fix: clear `adminCount` and re-enable inheritance on the object.


**Fine-Grained Password Policies still apply.** The Reset Password right does not override a PSO. A reset that violates the target's password policy (complexity, minimum age, length) simply fails. That is policy enforcement, not a permissions problem.

**Never delegate on the domain root.** Scope on the specific OU holding standard users. Targeting the domain head grants reset over every account in the directory, including privileged ones. Keep privileged accounts in their own OU that this delegation never touches.

**Removing the delegation.** To revoke cleanly (decommission, or moving to a different account):

cmd
```
dsacls "OU=TG_Users,DC=example,DC=com" /R "DOMAIN\svc-account"
```
`/R` strips every ACE for that principal on the object.