Organisaatiossa, jossa työskentelen, etätyö on periaatteessa kiellettyä. Oli. Viime viikkoon asti. Nyt oli kiireesti toteutettava ratkaisu. Liiketoiminnasta - prosessien mukauttaminen uuteen työmuotoon, meiltä - PKI PIN-koodeilla ja tunnuksilla, VPN, yksityiskohtainen kirjaus ja paljon muuta.
Olin muun muassa perustamassa Remote Desktop Infrastructurea eli Terminal Services -palvelua. Meillä on useita RDS-ratkaisuja eri datakeskuksissa. Yksi tavoitteista oli antaa IT-osastojen kollegoille mahdollisuus muodostaa interaktiivinen yhteys käyttäjäistuntoihin. Kuten tiedät, tätä varten on olemassa standardi RDS Shadow -mekanismi, ja helpoin tapa delegoida se on antaa paikallisen järjestelmänvalvojan oikeudet RDS-palvelimille.
Kunnioitan ja arvostan kollegoitani, mutta olen erittäin ahne järjestelmänvalvojan oikeuksien jakamisessa. 🙂 Ne, jotka ovat kanssani samaa mieltä, seuratkaa leikkausta.
No, tehtävä on selvä, nyt mennään asiaan.
Vaihe 1
Luodaan suojausryhmä Active Directoryyn RDP_Operators ja sisällytä siihen niiden käyttäjien tilit, joille haluamme siirtää oikeudet:
Jos sinulla on useita AD-sivustoja, sinun on odotettava, kunnes se replikoidaan kaikkiin toimialueen ohjaimiin, ennen kuin siirryt seuraavaan vaiheeseen. Tämä kestää yleensä enintään 15 minuuttia.
Vaihe 2
Annetaan ryhmälle oikeudet hallita pääteistuntoja kussakin RDSH-palvelimessa:
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")
}
}
}
Vaihe 3
Lisää ryhmä paikalliseen ryhmään Etätyöpöydän käyttäjät jokaisessa RDSH-palvelimessa. Jos palvelimesi on yhdistetty istuntokokoelmiksi, teemme tämän kokoelmatasolla:
Käytämme yksittäisille palvelimille ryhmäpolitiikka, odottaa, että se otetaan käyttöön palvelimilla. Ne, jotka ovat liian laiskoja odottamaan, voivat nopeuttaa prosessia käyttämällä mieluiten vanhaa hyvää gpupdatea keskitetysti.
Jotta PS-skriptin ajaminen olisi helppoa, luomme sille komentotulkin cmd-tiedostona, jolla on sama nimi kuin PS-skriptillä:
RDSManagement.cmd
@ECHO OFF
powershell -NoLogo -ExecutionPolicy Bypass -File "%~d0%~p0%~n0.ps1" %*
Laitamme molemmat tiedostot kansioon, joka on "johtajien" käytettävissä, ja pyydämme heitä kirjautumaan uudelleen sisään. Nyt suorittamalla cmd-tiedoston he voivat muodostaa yhteyden muiden käyttäjien istuntoihin RDS Shadow -tilassa ja pakottaa heidät kirjautumaan ulos (tämä voi olla hyödyllistä, kun käyttäjä ei voi itsenäisesti lopettaa "riippuvaa" istuntoa).
Se näyttää noin:
"johtajalle"
Käyttäjälle
Lopuksi muutama kommentti
Vivahde 1. Jos käyttäjäistunto, jonka hallintaa yritämme saada, käynnistettiin ennen kuin Set-RDSPermissions.ps1-komentosarja suoritettiin palvelimella, "hallinta" saa käyttövirheilmoituksen. Ratkaisu on ilmeinen: odota, kunnes hallittu käyttäjä kirjautuu sisään.
Vivahde 2. Useiden päivien työskentelyn jälkeen RDP Shadow'n kanssa havaitsimme mielenkiintoisen virheen tai ominaisuuden: varjoistunnon päätyttyä kielipalkin kielipalkki katoaa käyttäjältä, johon yhteys on muodostettu, ja saadaksesi sen takaisin käyttäjän on -Kirjaudu sisään. Kuten käy ilmi, emme ole yksin: aika, два, kolme.
Siinä kaikki. Toivon sinulle ja palvelijoillesi hyvää terveyttä. Kuten aina, odotan palautettasi kommenteissa ja pyydän sinua vastaamaan alla olevaan lyhyeen kyselyyn.