Во организацијата каде што работам, во принцип е забранета работа од далечина. Беше. До минатата недела. Сега моравме итно да спроведеме решение. Од бизнис - прилагодување на процесите на нов работен формат, од нас - PKI со PIN кодови и токени, VPN, детално логирање и многу повеќе.
Меѓу другото, поставував инфраструктура за далечинска работна површина или Терминални услуги. Имаме неколку распоредувања на 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, по можност централно.
Чекор 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, забележавме интересна грешка или функција: по завршувањето на сесијата во сенка, јазичната лента во фиоката исчезнува за корисникот со кој е поврзан, а за да ја врати, корисникот треба повторно да -Логирај Се. Како што се испостави, не сме сами: време, два, три.
Тоа е се. Ви посакувам добро здравје вам и на вашите сервери. Како и секогаш, со нетрпение ги очекувам вашите повратни информации во коментарите и ве замолувам да ја преземете кратката анкета подолу.