В организацията, в която работя, дистанционната работа е принципно забранена. Беше. До миналата седмица. Сега трябваше спешно да приложим решение. От бизнеса - адаптиране на процесите към нов формат на работа, от нас - PKI с ПИН кодове и токени, VPN, детайлно логване и много други.
Освен всичко друго, настройвах Remote Desktop Infrastructure, известна още като Terminal Services. Имаме няколко внедрявания на RDS в различни центрове за данни. Една от целите беше да се даде възможност на колеги от свързани ИТ отдели да се свързват интерактивно с потребителски сесии. Както знаете, има стандартен RDS Shadow механизъм за това и най-лесният начин да го делегирате е да дадете права на локален администратор на RDS сървъри.
Уважавам и ценя колегите си, но съм много алчен, когато става въпрос за раздаване на администраторски права. 🙂 За тези, които са съгласни с мен, моля, следвайте разреза.
Е, задачата е ясна, сега да се заемем с работата.
Стъпка 1
Нека създадем група за сигурност в Active Directory RDP_Оператори и включваме в него акаунтите на онези потребители, на които искаме да делегираме права:
Ако имате множество 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 забелязахме интересен бъг или функция: след края на shadow сесията езиковата лента в трея изчезва за потребителя, към който се свързва, и за да я върне, потребителят трябва да -Влизам. Както се оказва, не сме сами: път, два, три.
Това е всичко. Желая на вас и вашите сървъри добро здраве. Както винаги, очаквам вашите отзиви в коментарите и ви моля да участвате в краткото проучване по-долу.