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

# How to enable RDP to Entra ID joined devices for multiple users

### Why This Is Needed

When a Windows machine is Entra ID-joined (rather than traditional Active Directory-joined), users who need to connect via RDP must be explicitly added to the local **Remote Desktop Users** group on the target machine. By default, only local administrators can RDP into an Entra-joined device. In a traditional AD environment, this is typically handled via Group Policy. On Entra-joined machines, there is no Group Policy processing, so you need an alternative method to grant RDP access to your users.

This is a prerequisite for TruGrid to broker RDP connections to Entra-joined machines. If a user is not a local admin and is not a member of the Remote Desktop Users group on the target machine, the RDP session will be denied regardless of your TruGrid configuration.

TruGrid customers should have an Entra ID security group called **TG-USERS** that contains all users who need remote access through TruGrid. The methods below use this group as the example. If your group is named differently, substitute accordingly.

| NOTE: TruGrid has a SSO feature that, if prerequisites are satisfied allows for a better login experience, documentation regarding that can be found here: [How to Enable SSO Auth to On-Premises resources with Entra ID](https://help.trugrid.com/en/article/how-to-enable-sso-auth-to-on-premises-resources-with-entra-id-1jrefau/)

### Finding the Entra ID Group SID

If the `AzureAD\TG-USERS` name format doesn't work (common if the group hasn't been resolved on the device yet), you can use the SID instead.

**Option A: Look it up from a device where it already works**

```
Get-LocalGroupMember -Group "Remote Desktop Users" |
  Where-Object { $_.Name -like "AzureAD*" } |
  Select-Object Name, SID
```

**Option B: Convert the Entra Object ID to a SID**

Find the Object ID of your TG-USERS group in the Entra admin center (Groups > TG-USERS > Overview), then run:

```
$objectId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"  # Replace with your TG-USERS Object ID
$bytes = [System.Guid]::Parse($objectId).ToByteArray()
$parts = @()
for ($i = 0; $i -lt 16; $i += 4) {
    $parts += [BitConverter]::ToUInt32($bytes, $i)
}
$sid = "S-1-12-1-$($parts -join '-')"
Write-Output $sid
```

Then use the SID in any of the methods above instead of `AzureAD\TG-USERS`:

```
Add-LocalGroupMember -Group "Remote Desktop Users" -Member $sid
```

### Method 1: PowerShell (Direct Command)

Use this when you need to quickly add users or groups on one or a few machines. Run PowerShell as Administrator on each target machine.
**Add the TG-USERS Entra ID group:**

```
Add-LocalGroupMember -Group "Remote Desktop Users" -Member "AzureAD\TG-USERS"
```

**Add individual Entra ID users:**

```
Add-LocalGroupMember -Group "Remote Desktop Users" -Member "AzureAD\jsmith@contoso.com"
```

**Add multiple users at once:**

```
$users = @(
    "AzureAD\jsmith@contoso.com",
    "AzureAD\jdoe@contoso.com",
    "AzureAD\mbrown@contoso.com"
)

foreach ($user in $users) {
    try {
        Add-LocalGroupMember -Group "Remote Desktop Users" -Member $user -ErrorAction Stop
        Write-Output "Added $user"
    }
    catch {
        if ($_.Exception.Message -match "already a member") {
            Write-Output "$user is already a member, skipping."
        } else {
            Write-Warning "Failed to add $user : $_"
        }
    }
}
```

**Verify:**

```
Get-LocalGroupMember -Group "Remote Desktop Users"
```

| Note: If you get a "member not found" error using the AzureAD\Name format, the device may not have resolved that identity yet. In that case, use the SID instead. See the "Finding the SID" section at the bottom of this article.

### Method 2: Intune (Account Protection Policy)

Use this when you manage your devices through Microsoft Intune and want the membership to be continuously enforced. If someone manually removes the group, Intune will re-apply it on the next sync.

||| Warning: This method uses a REPLACE operation. It removes all existing members of the local Remote Desktop Users group and replaces them with only what you define in the policy. If you have existing local accounts that must remain in the group, include them explicitly in the policy.

**Steps:**

1. Open the **Microsoft Intune admin center** (intune.microsoft.com)
2. Navigate to **Endpoint Security > Account Protection**
3. Click **+ Create Policy**
4. Platform: **Windows 10 and later**
5. Profile: **Local user group membership**
6. Configure the settings:
    * Local group: **Remote Desktop Users**
    * Group and user action: **Add (Replace)**
    * User selection type: **Manual**
    * Selected user(s)/group(s): `AzureAD\TG-USERS`
7. On the Assignments page, target a **device group** containing your Entra-joined machines
8. Review and **Create**

To add individual users instead of or in addition to the group, add each user on a separate line in the same format: `AzureAD\jsmith@contoso.com`

**Verify on a target device after sync:**

```
Get-LocalGroupMember -Group "Remote Desktop Users"

# Force an Intune sync if you don't want to wait
Get-ScheduledTask | Where-Object {
  $_.TaskName -eq 'PushLaunch'
} | Start-ScheduledTask
```

**Making Intune append instead of replace:**

If you need to preserve existing members, deploy the script from Method 1 as an Intune Platform Script or Remediation instead of using the Account Protection policy:

1. Go to **Devices > Scripts and remediations > Platform scripts**
2. Click **+ Add > Windows 10 and later**
3. Upload a .ps1 file containing the script from Method 3 below
4. Settings: Run this script using the logged on credentials: **No**, Run script in 64-bit PowerShell Host: **Yes**
5. Assign to a device group

For continuous enforcement, deploy it as a **Remediation** with a detection script that checks for compliance and a remediation script that adds the group. See Method 3 for the scripts.

### Method 3: RMM Tool Deployment (NinjaOne, Datto, ConnectWise, etc.)

Use this when you manage devices through an RMM tool rather than Intune, or when you need to push the change to many machines at once without Intune. Most RMM platforms support running PowerShell scripts against device groups.

**Script: Add-TGUsers-to-RDP.ps1**

```
$LocalGroup = "Remote Desktop Users"

# --- Configure members to add ---
# Add the TG-USERS group and any individual users as needed.
# Remove or add lines as appropriate for your environment.
$MembersToAdd = @(
    "AzureAD\TG-USERS"
    # "AzureAD\jsmith@contoso.com"
    # "AzureAD\jdoe@contoso.com"
)

$ErrorActionPreference = 'Stop'
$results = @()

foreach ($member in $MembersToAdd) {
    try {
        $existing = Get-LocalGroupMember -Group $LocalGroup -ErrorAction SilentlyContinue |
            Where-Object { $_.Name -eq $member }

        if ($existing) {
            $results += "$member - already a member, skipped."
            continue
        }

        Add-LocalGroupMember -Group $LocalGroup -Member $member
        $results += "$member - added successfully."
    }
    catch {
        $results += "$member - FAILED: $_"
    }
}

# Output results for RMM logging
$results | ForEach-Object { Write-Output $_ }

# Final verification
Write-Output "`nCurrent members of ${LocalGroup}:"
Get-LocalGroupMember -Group $LocalGroup | Format-Table Name, ObjectClass, PrincipalSource
```

**How to deploy this depends on your RMM tool, but the general process is:**

1. Create a new script/task in your RMM platform
2. Paste or upload the script above
3. Set it to run as **SYSTEM** (not as the logged-in user)
4. Target the device group or individual machines that need it
5. Execute and review the output logs

### Method 4: CMD Script (net localgroup)

Use this when PowerShell is unavailable, restricted by policy, or when you just prefer the simplicity of net commands. This works as a .bat or .cmd file and can be pushed through any RMM tool.

**Quick manual commands (run CMD as Administrator):**

Add the TG-USERS Entra ID group:

```
net localgroup "Remote Desktop Users" "AzureAD\TG-USERS" /add
```

Add an individual Entra ID user:

```
net localgroup "Remote Desktop Users" "AzureAD\jsmith@contoso.com" /add
```

Verify:

```
net localgroup "Remote Desktop Users"
```

**Script: Add-TGUsers-to-RDP.cmd**

```
@echo off
REM Add-TGUsers-to-RDP.cmd
REM Adds the TG-USERS Entra ID group and/or individual users
REM to the local Remote Desktop Users group.
REM Deploy via your RMM tool's script execution feature.
REM Must run as SYSTEM or local Administrator.

echo ============================================
echo  TruGrid - Add members to Remote Desktop Users
echo ============================================
echo.

REM --- Configure members to add ---
REM Add or remove lines as needed for your environment.
REM Uncomment individual user lines if required.

call :AddMember "AzureAD\TG-USERS"
REM call :AddMember "AzureAD\jsmith@contoso.com"
REM call :AddMember "AzureAD\jdoe@contoso.com"

echo.
echo --- Current members of Remote Desktop Users ---
net localgroup "Remote Desktop Users"
echo.
echo Done.
exit /b 0

:AddMember
echo Adding %~1...
net localgroup "Remote Desktop Users" %1 /add 2>&1 | findstr /i /c:"completed successfully" /c:"already a member" >nul
if %errorlevel% equ 0 (
    net localgroup "Remote Desktop Users" %1 /add 2>&1 | findstr /i /c:"already a member" >nul
    if %errorlevel% equ 0 (
        echo   %~1 - already a member, skipped.
    ) else (
        echo   %~1 - added successfully.
    )
) else (
    echo   %~1 - FAILED. Check the name or use SID format.
)
exit /b
```

**RMM deployment:** Same process as Method 3, but select **CMD / Batch** as the script type instead of PowerShell. Set execution context to **SYSTEM**. The script is safe to run repeatedly -- `net localgroup /add` on an existing member just returns "already a member" and moves on.

||| Note: net localgroup does not support SID format directly. If the AzureAD\TG-USERS name won't resolve on the target device, you'll need to fall back to Method 1 or Method 3 using the SID. This is the main limitation of the CMD approach.