Una delle necessità di base se amministri o eroghi supporto IT è quella di interagire con l’utente: che sia troubleshooting o assistenza, puntualmente il nostro interlocutore sembra non sapere cosa sta facendo o le sue capacità di analisi e descrizione del problema sono pari a quelle dell’utente medio di un tablet Clementoni.

L’unico modo per salvare noi e il nostro sistema nervoso dall’utente sarà quindi vedere con i nostri occhi cosa sta succedendo sul suo Desktop con un software di Desktop Remoto tipo AnyDesk, Teamviewer e simili, pagando la relativa licenza se dovuta, oppure…

…oppure vediamo come fare tutto ciò utilizzando uno strumento che mamma Microsoft ci fornisce nativamente, anche se non molto pubblicizzato (sarà perchè è gratis?): Shadow Session

Si tratta in pratica di una sessione rdp che funziona in maniera molto simile ad Assistenza Remota di Windows, solo che non ha bisogno di una connessione internet e, soprattutto, l’utente dovrà semplicemente “accettare” la connessione con un click senza perdersi in ulteriori passaggi.

Come abilitare RDP Shadowing

Vediamo come fare in un ambiente di Dominio Active Directory, creiamo quindi una GPO e tramite Group Policy Management Editor andiamo in Computer Configuration / Administrative Templates / Windows components / Remote Desktop Services / Remote Session Host / Connections

Se non è già attivo abilitiamo il Desktop Remoto gpo abilita rdp e assicuriamoci di approfondire i parametri di sicurezza e le loro implicazioni (RTFM ci sta tutto), se siete pigri abilitate tutto e incrociate le dita gpo rdp security

A questo punto verifichiamo le impostazioni in Set rules for remote control of Remote Desktop Services user sessions. Di default tutti gli utenti appartenenti al gruppo Administrators sull’host remoto sono abilitati ad effettuare lo shadowing previo consenso dell’utente, personalmente mi sembra anche la scelta più indicata ma ovviamente adattatela al vostro contesto. gpo rdp shadow session permessi

Consentire RDP Shadowing sul Firewall

Purtroppo la famigerata porta RDP 3389 è assolutamente inutile in questo caso, infatti le sessioni shadow utilizzano la porta 445/TCP ed altre Ephemeral ports assolutamente dinamiche nel range 49152-65535/TCP, pertanto l’unica soluzione è consentirle in blocco sul Firewall. Nel caso del Firewall nativo di Windows possiamo abilitare due regole predefinite

  • File and Printer Sharing (SMB-In), in Italiano Condivisione File e Stampanti (SMB-In)
  • Remote Desktop - Shadow (TCP-In), Desktop remoto - Shadow (TCP-In)

L’ultima consente esclusivamente l’ascolto al processo RdpSa.exe

Connessione remota alla sessione utente con RDP Shadowing

Per avviare la connessione usiamo il client di Windows Remote Desktop ufficiale, sfortunatamente ad oggi non esiste l’opzione shadow nella GUI quindi toccherà avviarlo da linea di comando 

1

mstsc.exe /shadow:<Session ID> /v:<Computer name or IP address>

Queste è la sintassi di base ma possiamo anche specificare le opzioni di seguito

  • /prompt - Vi verrà chiesto di specificare utente e password con cui connettervi anzichè usare il vostro utente corrente
  • /control - Avrete il pieno controllo di mouse e tastiera remoti, senza passare questa opzione avrete accesso in sola visione alla sessione remota
  • /noConsentPrompt - Non verrà chiesto il consenso all’utente remoto per l’accesso alla sua sessione

Ci servirà infine il Session ID della sessione remota che possiamo ottenere sempre da linea di comando con 

1

qwinsta /server:<Computer name or IP address>

Ed ecco l’output dove vediamo che la sessione “Active” del nostro amato utente ha ID 1 cmd qwinsta

Possiamo quindi procedere alla connessione mstsc shadow connessione

L’utente riceverà la richiesta, con l’autorizzazione che richiediamo (visualizzare o controllare), che dovrà accettare offerta assistenza remota

E finalmente potremo vedere ed interagire con la sessione utente controllo sessione shadow

Facile no? Il qwinsta in molti casi ce lo potremmo risparmiare, tendenzialmente l’ID sessione, se non è un server, sarà quasi sempre 1 ma…visto che vogliamo essere pronti a tutto e non vogliamo romperci le p perdere tempo ecco un malefico .bat che ci renderà la vita migliore 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

@echo off
set session=0
set /p remotePc=Nome o IP computer: %=%
for /f "tokens=2-4" %%a in ('qwinsta /server:%remotePc%') do @if "%%c"=="Active" (
 set session=%%b
 set user=%%a
)
IF NOT "%session%"=="0" (
 echo "Connessione a %user%"
 start /max /wait mstsc.exe /v:%remotePc% /shadow:%session% /control
 exit
) ELSE (
 echo "Non ci sono utenti attivi"
)

Sì lo so, prima o poi lo convertirò in PowerShell ma un .bat per quanto malefico ha un indubbio vantaggio: è a portata di doppio click anche per il più basico degli utenti… sai mai che lo debba usare un babbano(cit.) dell’IT come vediamo di seguito.

RDP Shadowing senza diritti amministrativi

Di default solo gli amministratori possono creare sessioni shadow ma potrebbe darsi che questa funzionalità possa essere fondamentale anche per utenti non privilegiati, ad esempio utenti di supporto applicativo, e ovviamente non vogliamo dargli diritti amministrativi no? …NO!!!

Creiamo quindi un Security Group sul nostro dominio Active Directory e lo popoliamo con gli utenti standard che forniranno supporto nuovo security group

Poi diamo i permessi a questo gruppo via shell, come shell?! Già, nessuna GPO ci può aiutare e nemmeno una voce di registro, quello che dovremo fare sarà quindi lanciare questo PowerShell sul computer che riceverà la connessione 

1
2
3

#NB: Permessi saranno attivi solo dopo un riavvio
$obj = get-wmiobject -Name "root\CIMV2\terminalservices" -Class "Win32_TSPermissionsSetting"| Where-Object TerminalName -eq "Console"
$obj.AddAccount("contoso.local\RDP_SHADOW-Users",2)

E se me ne pento? Per resettare i permessi standard ecco la funzione inversa 

1
2
3

#NB: Permessi saranno attivi solo dopo un riavvio
$obj = get-wmiobject -Name "root\CIMV2\terminalservices" -Class "Win32_TSPermissionsSetting"| Where-Object TerminalName -eq "Console"
$obj.RestoreDefaults()

Considerazioni

Quanto visto si rivela molto utile in reti di dominio dove abbiamo la possibilità di accedere direttamente alle macchine via LAN/VPN/MPLS, e/o dove queste non hanno accesso a internet per usare software tipo Anydesk, Teamviewer ecc.

Condizione necessaria è ovviamente l’adeguato setting del Firewall software in esecuzione sui client, meglio se abilitato solo per le reti di Profilo Dominio.

Non male per essere free no? Voi a cosa vi affidate per il supporto remoto?

Sentitevi liberi di condividere le vostre esperienze nei commenti, a presto.