Այն կազմակերպությունում, որտեղ ես աշխատում եմ, հեռավար աշխատանքը սկզբունքորեն արգելված է։ Եղել է. Մինչև անցյալ շաբաթ։ Այժմ մենք պետք է շտապ լուծում իրականացնեինք. Բիզնեսից՝ գործընթացների հարմարեցում աշխատանքային նոր ձևաչափին, մեզանից՝ PKI PIN կոդերով և նշաններով, VPN, մանրամասն գրանցում և շատ ավելին:
Ի թիվս այլ բաների, ես կարգավորում էի Remote Desktop Infrastructure-ը, որը կոչվում է Terminal Services: Մենք ունենք մի քանի RDS տեղակայումներ տարբեր տվյալների կենտրոններում: Նպատակներից մեկն էր հնարավորություն ընձեռել համապատասխան ՏՏ բաժինների գործընկերներին ինտերակտիվ կերպով միանալ օգտատերերի նիստերին: Ինչպես գիտեք, դրա համար կա ստանդարտ RDS Shadow մեխանիզմ, և դա պատվիրակելու ամենահեշտ ձևը տեղական ադմինիստրատորի իրավունքներ տալն է RDS սերվերների վրա:
Ես հարգում և գնահատում եմ իմ գործընկերներին, բայց ես շատ ագահ եմ, երբ խոսքը վերաբերում է ադմինի իրավունքի բաժանմանը: 🙂 Ինձ հետ համամիտներին խնդրում եմ հետևել կտրվածքին։
Դե, խնդիրը պարզ է, հիմա եկեք անցնենք գործին:
Քայլ 1
Եկեք ստեղծենք անվտանգության խումբ Active Directory-ում RDP_Օպերատորներ և դրանում ներառեք այն օգտատերերի հաշիվները, որոնց մենք ցանկանում ենք պատվիրակել իրավունքները.
Եթե դուք ունեք բազմաթիվ AD կայքեր, դուք պետք է սպասեք, մինչև այն կրկնօրինակվի բոլոր տիրույթի կարգավորիչներին՝ նախքան հաջորդ քայլին անցնելը: Դա սովորաբար տևում է ոչ ավելի, քան 15 րոպե:
$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, գերադասելի է կենտրոնացված.
Քայլ 4
Եկեք պատրաստենք հետևյալ PS սցենարը «մենեջերների» համար.
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-ի հետ մի քանի օր աշխատելուց հետո մենք նկատեցինք մի հետաքրքիր սխալ կամ առանձնահատկություն. ստվերային սեսիայի ավարտից հետո սկուտեղի լեզվի տողը անհետանում է միացված օգտատիրոջ համար, և այն վերադարձնելու համար օգտագործողը պետք է նորից - մուտք. Ինչպես պարզվում է, մենք միայնակ չենք. ժամանակ, два, երեք.
Այսքանը: Մաղթում եմ ձեզ և ձեր սերվերներին առողջություն: Ինչպես միշտ, ես անհամբեր սպասում եմ ձեր կարծիքին մեկնաբանություններում և խնդրում եմ ձեզ մասնակցել ստորև ներկայացված կարճ հարցմանը: