В организации, где я работаю, удаленка запрещена в принципе. Была. До прошлой недели. Теперь пришлось в срочном порядке внедрять решение. От бизнеса — адаптация процессов к новому формату работы, от нас — PKI с пин-кодами и токенами, VPN, детальное логирование и много чего ещё. Помимо всего прочего, я занимался настройкой инфраструктуры удаленных рабочих столов aka службы терминалов. У нас несколько RDS-развертываний в разных ЦОДах. Одной из задач было дать возможность коллегам из смежных подразделений ИТ подключаться к пользовательским сеансам в интерактивном режиме. Как известно, для этого есть штатный механизм RDS Shadow и самый простой способ его делегировать — дать права локального администратора на RDS-серверах. Я уважаю и ценю своих коллег, но очень жадный до раздачи админских прав. 🙂 Тех, кто со мной солидарен, прошу под кат. Что ж, задача ясна, теперь — к делу.
Шаг 1
Создадим в Active Directory группу безопасности RDP_Operators и включим в нее учётные записи тех пользователей, которым хотим делегировать права:
Если у вас несколько AD-сайтов, то перед тем, как перейти к следующему шагу, нужно подождать, пока она будет реплицирована на все контроллеры домена. Обычно это занимает не более 15 минут.
Шаг 2
Дадим группе права на управление терминальными сессиями на каждом из RDSH-серверов:
Set-RDSPermissions.ps1
$Group = "RDP_Operators"
$Servers = @(
"RDSHost01",
"RDSHost02",
"RDSHost03"
)
ForEach ($Server in $Servers) {
#Делегируем право на теневые сессии
$WMIHandles = Get-WmiObject `
-Class "Win32_TSPermissionsSetting" `
-Namespace "rootCIMV2terminalservices" `
-ComputerName $Server `
-Authentication PacketPrivacy `
-Impersonation Impersonate
ForEach($WMIHandle in $WMIHandles)
{
If ($WMIHandle.TerminalName -eq "RDP-Tcp")
{
$retVal = $WMIHandle.AddAccount($Group, 2)
$opstatus = "успешно"
If ($retVal.ReturnValue -ne 0) {
$opstatus = "ошибка"
}
Write-Host ("Делегирование прав на теневое подключение группе " +
$Group + " на сервере " + $Server + ": " + $opstatus + "`r`n")
}
}
}
Шаг 3
Добавим группу в локальную группу Пользователи удаленного рабочего стола на каждом из RDSH-серверов. Если у вас серверы объединены в коллекции сеансов, то делаем это на уровне коллекции:
Для одиночных серверов задействуем групповую политику, дождавшись, пока она применится на серверах. Те, кому лень ждать, могут форсировать процесс с помощью старого доброго gpupdate, желательно централизованно.
Чтобы PS-скрипт было удобно запускать, сделаем для него оболочку в виде cmd-файла с таким же именем, как у PS-скрипта:
RDSManagement.cmd
@ECHO OFF
powershell -NoLogo -ExecutionPolicy Bypass -File "%~d0%~p0%~n0.ps1" %*
Кладем оба файла в папку, которая будет доступна «управленцам» и просим их перелогиниться. Теперь, запустив cmd-файл, они смогут подключаться к сессиям других пользователей в режиме RDS Shadow и принудительно их разлогинивать (бывает полезно, когда пользователь не может самостоятельно завершить «зависшую» сессию).
Выглядит это примерно так:
Для «управленца»
Для пользователя
Несколько замечаний напоследок
Нюанс 1. Если сеанс пользователя, к которому пытаемся получить управление, был запущен до того, как на сервере отработал скрипт Set-RDSPermissions.ps1, то «управленец» получит ошибку доступа. Решение здесь очевидно: подождать, пока управляемый пользователь перелогинится.
Нюанс 2. После нескольких дней работы с RDP Shadow заметили интересный то ли баг, то ли фичу: после завершения теневого сеанса у пользователя, к которому подключались, пропадает языковая панель в трее и чтобы ее вернуть, пользователю нужно перелогиниться. Как оказалось, мы не одиноки: раз, два, три.
На этом всё. Желаю здоровья вам и вашим серверам. Как всегда, жду обратной связи в комментариях и прошу пройти небольшой опрос ниже.