Organisatsioonis, kus ma töötan, on kaugtöö põhimõtteliselt keelatud. Oli. Kuni eelmise nädalani. Nüüd tuli kiiremas korras lahendus ellu viia. Ärist – protsesside kohandamine uuele töövormingule, meilt – PIN-koodide ja žetoonidega PKI, VPN, detailne logimine ja palju muud.
Muuhulgas seadistasin kaugtöölaua infrastruktuuri ehk terminaliteenuseid. Meil on erinevates andmekeskustes mitu RDS-i juurutamist. Üks eesmärke oli võimaldada seotud IT-osakondade kolleegidel interaktiivselt kasutajaseanssidega ühenduda. Teatavasti on selleks standardne RDS Shadow mehhanism ja lihtsaim viis selle delegeerimiseks on anda RDS-serverites kohaliku administraatori õigused.
Ma austan ja hindan oma kolleege, kuid olen väga ahne, kui asi puudutab administraatoriõiguste jagamist. 🙂 Kes on minuga nõus, jälgige lõiget.
Noh, ülesanne on selge, asume nüüd asja juurde.
Samm 1
Loome Active Directorysse turvarühma RDP_Operaatorid ja lisage sellesse nende kasutajate kontod, kellele tahame õigusi delegeerida:
Kui teil on mitu AD-saiti, peate enne järgmise sammu juurde liikumist ootama, kuni see kopeeritakse kõigile domeenikontrolleritele. See ei kesta tavaliselt rohkem kui 15 minutit.
Samm 2
Anname rühmale õigused terminaliseansside haldamiseks igas RDSH-serveris:
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")
}
}
}
Samm 3
Lisage rühm kohalikku gruppi Kaugtöölaua kasutajad igas RDSH-serveris. Kui teie serverid on ühendatud seansikogudeks, teeme seda kogude tasemel:
Kasutame üksikute serverite jaoks rühmapoliitika, oodates selle rakendamist serverites. Need, kes on ootama liiga laisad, saavad protsessi kiirendada, kasutades eelistatavalt vana head gpupdate'i tsentraalselt.
Samm 4
Valmistame ette järgmise PS-skripti "halduritele":
PS-skripti käitamise mugavamaks muutmiseks loome selle jaoks kesta cmd-failina, millel on sama nimi kui PS-skriptil:
RDSManagement.cmd
@ECHO OFF
powershell -NoLogo -ExecutionPolicy Bypass -File "%~d0%~p0%~n0.ps1" %*
Panime mõlemad failid kausta, mis on "halduritele" juurdepääsetav, ja palume neil uuesti sisse logida. Nüüd saavad nad cmd-faili käivitades luua ühenduse teiste kasutajate seanssidega RDS Shadow režiimis ja sundida neid välja logima (see võib olla kasulik, kui kasutaja ei saa iseseisvalt rippuvat seanssi lõpetada).
See näeb välja umbes selline:
"Juhataja" jaoks
Kasutaja jaoks
Mõned viimased kommentaarid
Nüanss 1. Kui kasutajaseanss, mille üle me kontrolli püüame saada, käivitati enne, kui serveris käivitati skript Set-RDSPermissions.ps1, siis saab "haldur" juurdepääsutõrketeate. Lahendus on siin ilmne: oodake, kuni hallatav kasutaja sisse logib.
Nüanss 2. Pärast mitut päeva RDP Shadowiga töötamist märkasime huvitavat viga või funktsiooni: pärast variseansi lõppu kaob salves olev keeleriba kasutaja jaoks, kellega ühenduses on, ja selle tagasi saamiseks peab kasutaja uuesti -Logi sisse. Nagu selgub, pole me üksi: aeg, два, kolm.
See on kõik. Soovin teile ja teie teenindajatele head tervist. Nagu alati, ootan teie tagasisidet kommentaarides ja palun teil täita alljärgnev lühike küsitlus.