RDP-Tcp права пользователей - Компьютерный форум OSzone.net

Компьютерный форум OSzone.net (http://forum.oszone.net/index.php)

- Windows Server 2016/2019/2022 (http://forum.oszone.net/forumdisplay.php?f=119)

- - RDP-Tcp права пользователей (http://forum.oszone.net/showthread.php?t=343841)

RDP-Tcp права пользователей

Изначальная задача - дать возможность пользователям (а лучше группам), НЕ являющими локальными администраторами ни на одном из серверов (RD Deployment), получать список терминальных сессий, слать в них сообщение и принудительно завершать сессию (force logoff).

Если издалека - давным давно во времена 2008го сервера существовала утилитка Remote Desktop Session Host Configuration, которая позволяла с помощью виндового же графического интерфейса задавать те самые права пользователям или группам, выглядело это всё вот так:

Скрытый текст

Злобные дядьки из мелкософта, зачем-то, выпилили эту утилиту. А вот альтернативного способа добраться до этих настроек, видать, не оставили. Во всяком случае я не нашёл, буду благодарен если кто-то подскажет упущенный способ добраться до этих настроек.

В попытках докопаться до возможности менять эти права я дошел аж до WMI класса Win32_TSAccount class, каждый экземпляр которого и описывает права для определенной группы.
С помощью WMI Explorer'a я вижу все эти инстансы и соответствующие им права:

Скрытый текст

У класса Win32_TSAccount есть методы Delete, ModifyAuditPermissions и ModifyPermissions. Последнее в принципе должно работать, но химичить с правами на стандартных учетках не хочется потому что мало ли какие последствия вылезут да и хочется всё-таки доменную группу добавить.

Вопрос - как добавить еще один инстанс?
Или более глобальный вопрос - каким другим (возможно менее наркоманским) способом можно дать доменной группе право подключиться внутрь сессий пользователей, принудительно завершать её и отправлять сообщение внутрь сессии НЕ давая админку?

Небольшой апдейт - разобрался как добавить пользователя\группу как экземпляр класса Win32_TSAccount, делается это так:

Powershell

Код:

$myuser = "DOMAIN\samaccountname"



$PermissionPreSet = 2

<#

0 = WINSTATION_GUEST_ACCESS => Permissions: Logon

1 = WINSTATION_USER_ACCESS => Permissions: Logon, QueryInformation, SendMessage and Connect

2 = WINSTATION_ALL_ACCESS => All RDS permissions

https://docs.microsoft.com/en-us/windows/win32/termserv/win32-tspermissionssetting-addaccount

#>



$computer = $env:COMPUTERNAME # TS SESSION HOST

$namespace = "ROOT\CIMV2\TerminalServices"

$PermissionsClassName = "Win32_TSPermissionsSetting"



$wmiTSPermissionsSetting = Get-WmiObject -Class $PermissionsClassName -ComputerName $computer -Namespace $namespace | Where-Object -FilterScript {$_.TerminalName -eq "RDP-Tcp"}

$wmiTSPermissionsSettingResult = Invoke-WmiMethod -InputObject $wmiTSPermissionsSetting -Name "AddAccount" -ArgumentList $myuser,$PermissionPreSet

Теперь, если у пользователя или группы, добавленной таким образом, есть возможность подключаться по WinRM к серверу - они могут пользоваться командлетами Send-RDUserMessage и Invoke-RDUserLogoff указывая напрямую ID сеанса + сервер с ролью Session Host, на котором хостится этот сеанс.
Только проблема в том что этот номер сеанса надо как-то узнать, и делается это так:

Код:

Get-RDUserSession -ConnectionBroker $brokerFQDN

И в ответ я получаю:

Цитата:

PS C:\windows\system32> Get-RDUserSession -ConnectionBroker $ConnectionBroker
Get-RDUserSession : На srv-tshost-test.company.com не развернуты службы удаленных
рабочих столов. Эту операцию можно выполнить после их развертывания. Для получения
дополнительных сведений о развертывании выполните командлет "Get-Help
New-RDVirtualDesktopDeployment" или "Get-Help New-RDSessionDeployment".
строка:1 знак:1
+ Get-RDUserSession -ConnectionBroker $ConnectionBroker
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Get-RDUserSession

При этом консольный вариант query session /server:srv-tshost-test работает, что говорит о наличии необходимого минимума прав.
А вот командлету Get-RDUserSession каких-то прав таки не хватает.

В обсуждениях на форумах я встречал различные мнения, но несколько раз (например тут) натыкался на такое мнение что в процессе работы командлет Get-RDUserSession проводит целый ряд проверок "а является ли target-host частью RDS Deployment", и одна из таких проверок - командлет делает `Get-Service RDMS -Computername $target`. Я проверил и у пользователя действительно нет прав посмотреть на эту службу удалённо (PoSh говорит что служба не найдена). А если локально на сервере под этим же пользователем зайти - права уже есть.
Я не уверен на 100% в этом ли причина неработоспособности командлета Get-RDUserSession но вроде похоже не правду.
По ссылке из предыдущего абзаца даже есть обходной путь, но там слишком много ручных действий и вообще похоже больше на костыль чем решение, я бы предпочел таки дать выделенной группе пользователей все необходимые права и таки дать им возможность пользоваться "родными" средствами, а не костылить.
Есть идеи как это можно сделать?