Na organización onde traballo, o traballo a distancia está prohibido en principio. Foi. Ata a semana pasada. Agora tiñamos que implementar urxentemente unha solución. Desde as empresas: adaptación de procesos a un novo formato de traballo, de nós: PKI con códigos PIN e tokens, VPN, rexistro detallado e moito máis.
Entre outras cousas, estaba configurando a Infraestrutura de Escritorio Remoto tamén coñecido como Servizos de Terminal. Temos varios despregamentos de RDS en diferentes centros de datos. Un dos obxectivos era permitir que os compañeiros dos departamentos de TI relacionados se conectaran ás sesións dos usuarios de forma interactiva. Como sabes, hai un mecanismo de sombra RDS estándar para iso, e a forma máis sinxela de delegalo é dar dereitos de administrador local nos servidores RDS.
Respecto e valoro aos meus compañeiros, pero son moi cobizoso á hora de repartir dereitos de administrador. 🙂 Para os que estean de acordo comigo, sigan o corte.
Ben, a tarefa está clara, agora imos mans á obra.
Paso 1
Imos crear un grupo de seguridade en Active Directory RDP_Operadores e incluír nela as contas daqueles usuarios nos que queremos delegar dereitos:
Se tes varios sitios de AD, terás que esperar ata que se replique en todos os controladores de dominio antes de pasar ao seguinte paso. Isto normalmente non leva máis de 15 minutos.
Paso 2
Dámoslle ao grupo dereitos para xestionar sesións de terminal en cada un dos servidores 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")
}
}
}
Paso 3
Engade o grupo ao grupo local Usuarios de escritorio remoto en cada un dos servidores RDSH. Se os teus servidores se combinan en coleccións de sesións, facemos isto a nivel de colección:
Para servidores únicos que usamos política de grupo, á espera de que se aplique nos servidores. Os que teñan preguiza para esperar poden acelerar o proceso usando o bo gpupdate antigo, preferiblemente centralmente.
Paso 4
Imos preparar o seguinte script de PS para "xestores":
Para que o script PS sexa cómodo de executar, crearemos un shell para el en forma de ficheiro cmd co mesmo nome que o script PS:
RDSManagement.cmd
@ECHO OFF
powershell -NoLogo -ExecutionPolicy Bypass -File "%~d0%~p0%~n0.ps1" %*
Poñemos ambos ficheiros nun cartafol ao que poderán acceder os "xestores" e pedímoslles que volvan iniciar sesión. Agora, ao executar o ficheiro cmd, poderán conectarse ás sesións doutros usuarios no modo RDS Shadow e obrigalos a pechar sesión (isto pode ser útil cando o usuario non pode finalizar de forma independente unha sesión "colgada").
Parece algo así:
Para o "xerente"
Para o usuario
Uns comentarios finais
Matiz 1. Se a sesión de usuario sobre a que estamos tentando controlar se lanzou antes de que o script Set-RDSPermissions.ps1 se executase no servidor, entón o "xestor" recibirá un erro de acceso. A solución aquí é obvia: agarde ata que o usuario xestionado inicie sesión.
Matiz 2. Despois de varios días de traballar con RDP Shadow, observamos un erro ou función interesante: despois do final da sesión de sombra, a barra de idioma da bandexa desaparece para o usuario ao que se está conectado e, para recuperalo, o usuario ten que volver -Iniciar sesión. Polo que se ve, non estamos sós: tempo, два, tres.
Iso é todo. Deséxoche boa saúde a ti e aos teus servidores. Coma sempre, espero os teus comentarios nos comentarios e pídoche que fagas a pequena enquisa a continuación.