Nell’organizzazione in cui lavoro, il lavoro a distanza è in linea di principio vietato. Era. Fino alla settimana scorsa. Ora dovevo implementare urgentemente una soluzione. Dal business - adattamento dei processi a un nuovo formato di lavoro, da noi - PKI con codici PIN e token, VPN, registrazione dettagliata e molto altro.
Tra le altre cose, sono stato coinvolto nella creazione dell'infrastruttura desktop remoto, ovvero Servizi terminal. Abbiamo diverse implementazioni RDS in diversi data center. Uno degli obiettivi era consentire ai colleghi dei reparti IT correlati di connettersi alle sessioni utente in modo interattivo. Come sai, esiste un normale meccanismo RDS Shadow per questo e il modo più semplice per delegarlo è concedere i diritti di amministratore locale sui server RDS.
Rispetto e apprezzo i miei colleghi, ma sono molto avido nella distribuzione dei diritti di amministratore. 🙂 Chi è d'accordo con me, per favore sotto cat.
Bene, ora il compito è chiaro: gli affari.
Passo 1
Crea un gruppo di sicurezza in Active Directory RDP_Operatori e includere in esso gli account degli utenti a cui vogliamo delegare i diritti:
Se disponi di più siti AD, prima di passare al passaggio successivo è necessario attendere la replica su tutti i controller di dominio. Di solito non ci vogliono più di 15 minuti.
Passo 2
Diamo al gruppo i diritti per gestire le sessioni terminale su ciascuno dei server 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")
}
}
}
Passo 3
Aggiungi un gruppo a un gruppo locale Utenti desktop remoti su ciascuno dei server RDSH. Se i tuoi server sono combinati in raccolte di sessioni, lo facciamo a livello di raccolta:
Per server singoli, utilizzare politica di gruppo, in attesa che venga applicato sui server. Per quelli troppo pigri per aspettare, è possibile forzare il processo con il buon vecchio gpupdate, preferibilmente centralmente.
Per rendere conveniente l'esecuzione dello script PS, creeremo una shell sotto forma di file cmd con lo stesso nome dello script PS:
RDSManagement.cmd
@ECHO OFF
powershell -NoLogo -ExecutionPolicy Bypass -File "%~d0%~p0%~n0.ps1" %*
Inseriamo entrambi i file in una cartella che sarà disponibile ai "gestori" e chiediamo loro di effettuare nuovamente l'accesso. Ora, eseguendo il file cmd, potranno connettersi alle sessioni di altri utenti in modalità RDS Shadow e forzarli al logout (è utile quando l'utente non riesce a terminare da solo la sessione “bloccata”).
Sembra qualcosa del genere:
Per "direttore"
Per l'utente
Alcune ultime osservazioni
Sfumatura 1. Se la sessione dell'utente di cui stiamo cercando di ottenere il controllo è stata avviata prima che lo script Set-RDSPermissions.ps1 fosse eseguito sul server, il "manager" riceverà un errore di accesso. La soluzione qui è ovvia: attendere che l'utente gestito esegua nuovamente l'accesso.
Sfumatura 2. Dopo diversi giorni di lavoro con RDP Shadow, hanno notato un bug o una funzionalità interessante: dopo la fine della sessione shadow, l'utente a cui si sono connessi scompare dalla barra della lingua nella barra delle applicazioni e, per ripristinarla, l'utente deve effettuare nuovamente l'accesso. A quanto pare, non siamo soli: tempo, два, tre.
È tutto. Auguro salute a te e ai tuoi servitori. Come sempre, attendo con ansia il tuo feedback nei commenti e ti chiedo di partecipare a un breve sondaggio qui sotto.