У арганізацыі, дзе я працую, выдаленне забаронена ў прынцыпе. Была. Да мінулага тыдня. Цяпер прыйшлося ў тэрміновым парадку ўкараняць рашэнне. Ад бізнэсу - адаптацыя працэсаў да новага фармату працы, ад нас - 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 заўважылі цікавы ці то баг, ці то фічу: пасля завяршэння ценявага сеансу ў карыстача, да якога падлучаліся, знікае моўная панэль у трэі і каб яе вярнуць, карыстачу трэба пералагініцца. Як аказалася, мы не самотныя: раз, два, 3.
На гэтым усё. Жадаю здароўя вам і вашым серверам. Як заўсёды, чакаю зваротнай сувязі ў каментарах і прашу прайсці невялікае апытанне ніжэй.