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:

The special Sentry, running as a suitably permissioned service account.
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

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

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

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.

Updated on: 02/07/2026

Was this article helpful?

Thank you!