Errore RDP: autenticazione a livello di rete non riuscita

Digiti nome utente e password nella connessione Desktop remoto, fai clic su Connetti e, prima che compaia una qualsiasi schermata di accesso, arriva un messaggio di errore. Nessun desktop, nessuna barra di caricamento, niente. È esattamente questo il segno distintivo di un problema NLA: l'autenticazione a livello di rete avviene prima che la sessione venga creata. Se fallisce, non vedrai mai una maschera di accesso in cui poter correggere qualcosa.

Questo articolo passa in rassegna le cause realistiche nell'ordine in cui si presentano nella pratica e mostra, per ognuna, il comando di verifica, la soluzione e la via di ritorno quando RDP è completamente morto.

I messaggi di errore alla lettera

Non esiste un solo messaggio, ma una manciata, e il testo esatto restringe già parecchio il campo delle cause. Queste varianti sono quelle che incontri più spesso:

• "Il computer remoto richiede l'autenticazione a livello di rete, che non è supportata dal computer in uso." Il server pretende NLA, il client non lo fornisce. Tipico con client datati, con client di terze parti su Linux o macOS e con criteri client impostati male.
• "Si è verificato un errore di autenticazione. Impossibile contattare l'autorità di sicurezza locale." In inglese: "The Local Security Authority cannot be contacted". È il classico messaggio da certificato oppure da orologio sfasato.
• "Si è verificato un errore di autenticazione. La funzione richiesta non è supportata." Qui si tratta quasi sempre di CredSSP, non di NLA in senso stretto. Più sotto i dettagli.
• "Le credenziali utilizzate per la connessione non hanno funzionato." Account bloccato, disattivato, password scaduta oppure account assente dal gruppo Utenti desktop remoto.
• "Impossibile stabilire la relazione di trust tra questa workstation e il dominio primario." L'account computer nel dominio non corrisponde più.

Importante per distinguere i casi: se dopo venti secondi il client segnala che il computer remoto non è raggiungibile, non è un errore NLA, ma rete, firewall o un servizio non in esecuzione. Gli errori NLA arrivano in fretta, di solito entro uno o tre secondi, perché la connessione TCP è già stabilita e a fallire è soltanto l'autenticazione.

Causa 1: orario sfasato tra client e server

È di gran lunga la causa più frequente ed è anche quella che si trascura più spesso, perché "l'orologio va un po' male" suona come un problema innocuo. Non lo è. Con un orario sfasato due meccanismi si rompono subito:

• Kerberos tollera per impostazione predefinita al massimo cinque minuti di scostamento. Oltre quella soglia il controller di dominio rifiuta la richiesta con KRB_AP_ERR_SKEW. Riguarda tutti i membri del dominio.
• La verifica TLS del certificato RDP fallisce quando l'orologio del client si trova fuori dal periodo di validità del certificato del server. Questo colpisce anche i server singoli senza dominio, e succede esattamente quando il server si riavvia con un orologio nel passato e un certificato appena generato, dal punto di vista del client, non è ancora valido.

Verifica sul server, in una PowerShell con diritti di amministratore:

w32tm /query /status /verbose
w32tm /query /source
w32tm /stripchart /computer:ptbtime1.ptb.de /samples:5 /dataonly

Lo stripchart ti restituisce lo scostamento in secondi. Tutto ciò che sta sotto un secondo va bene, tutto ciò che supera i 60 secondi è sospetto, tutto ciò che supera i 300 secondi spiega l'errore.

Qui i sistemi si dividono, e la maggior parte delle guide mette tutto nello stesso calderone:

• Server singolo senza dominio: imposta una sorgente NTP esterna.
• Membro di dominio: non impostare in nessun caso una lista di peer propria. Un server membro deve prendere l'ora dalla gerarchia del dominio, altrimenti va alla deriva rispetto al controller di dominio.

w32tm /config /manualpeerlist:"ptbtime1.ptb.de,0x9 time.windows.com,0x9" /syncfromflags:manual /update

w32tm /config /syncfromflags:domhier /update

Dopodiché, in entrambi i casi, riavvia il servizio e sincronizza:

net stop w32time
net start w32time
w32tm /resync /rediscover

Una particolarità che ti coglie sui server virtualizzati: se l'orologio sbaglia esattamente di una o due ore, non si tratta di deriva ma di un problema di interpretazione dell'orologio hardware. Windows si aspetta l'RTC in ora locale, molte piattaforme di virtualizzazione la forniscono in UTC. Controlla prima il fuso orario e poi, se serve, cambia l'interpretazione:

tzutil /g
tzutil /s "W. Europe Standard Time"

reg add "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /t REG_DWORD /d 1 /f

Causa 2: certificato scaduto o associato in modo errato

Senza una PKI propria, Windows genera per RDP un certificato autofirmato valido circa sei mesi, che di norma si rinnova da solo. "Di norma" è la parola chiave. Se il rinnovo fallisce per questioni di permessi nell'archivio delle chiavi, oppure se scade un certificato associato a mano e proveniente da una CA interna, non riesci più ad accedere e vedi il messaggio sull'autorità di sicurezza locale.

Controlla cosa c'è:

Get-ChildItem "Cert:\LocalMachine\Remote Desktop" | Select-Object Subject, NotBefore, NotAfter, Thumbprint

E subito dopo, quale certificato usa davvero il listener:

(Get-CimInstance -Namespace root\cimv2\terminalservices -ClassName Win32_TSGeneralSetting -Filter "TerminalName='RDP-tcp'").SSLCertificateSHA1Hash

Confronta l'hash restituito con i thumbprint del primo comando. Sono possibili due quadri: l'hash punta a un certificato scaduto, oppure punta a un certificato che nell'archivio non esiste più.

La riparazione consiste nel rimuovere l'associazione ed eliminare il vecchio certificato. Windows ne genera uno nuovo all'avvio del servizio:

Remove-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name SSLCertificateSHA1Hash -ErrorAction SilentlyContinue

Get-ChildItem "Cert:\LocalMachine\Remote Desktop" | Where-Object { $_.NotAfter -lt (Get-Date) } | Remove-Item

Restart-Service TermService -Force

Due avvertenze. Primo: il riavvio di TermService chiude tutte le sessioni RDP esistenti, compresa la tua, se in qualche modo sei ancora dentro. Esegui l'operazione dalla console. Secondo: se un criterio di gruppo impone un modello di certificato per l'autenticazione server, il server richiede il certificato alla CA interna. Se la CA non è raggiungibile oppure il modello è scaduto, non arriva nessun certificato nuovo e l'errore resta. In quel caso controlla prima la CA, non il server.

Controllo del risultato: il primo comando restituisce ora un certificato con una data NotAfter nel futuro, e SSLCertificateSHA1Hash punta esattamente a quello.

Causa 3: account bloccato, disattivato o password scaduta

Qui si nasconde la trappola che distingue NLA da tutti gli altri problemi di accesso: con NLA attivo non puoi cambiare una password scaduta attraverso il client RDP. La finestra "La password è scaduta e deve essere cambiata" compare solo dentro la sessione, e alla sessione non arrivi senza aver superato l'autenticazione. Il client si limita invece a segnalare che le credenziali non funzionano. La password è del tutto corretta, è soltanto scaduta.

Per vedere lo stato di un account locale:

net user Administrator

Fai attenzione alle righe "Account attivo", "Scadenza account", "Scadenza password" e "Password modificabile". Le contromisure adatte:

net user Administrator "NuovaPasswordLunga!2026"

Enable-LocalUser -Name "Administrator"

Set-LocalUser -Name "Administrator" -PasswordNeverExpires $true

Un account locale bloccato dopo troppi tentativi falliti è uno stato a sé, che non viene rimosso né da Enable-LocalUser né da un cambio di password. Si sblocca da solo alla scadenza della durata del blocco, che consulti così:

net accounts

Per sbloccare subito, senza strumenti grafici, si passa da ADSI:

$u = [ADSI]"WinNT://./Administrator,user"; $u.IsAccountLocked = $false; $u.SetInfo()

Se le porte RDP sono raggiungibili da internet, i blocchi arrivano praticamente ogni giorno, perché i bot provano a indovinare le credenziali del tuo account amministratore. È un argomento forte per limitare l'accesso, invece di sbloccare l'account all'infinito. Cambiare porta aiuta in modo sensibile contro le scansioni di massa, vedi Cambiare la porta RDP senza riavvio.

Infine l'appartenenza al gruppo. Il nome del gruppo è localizzato, cosa che manda spesso in crisi gli script. In modo indipendente dalla lingua interroghi il gruppo tramite il SID noto:

Get-LocalGroupMember -SID "S-1-5-32-555"

Causa 4: NLA disattivato o disattivato a metà sul server

Due interruttori separati determinano il comportamento, ed è proprio la loro combinazione a creare guai. UserAuthentication governa NLA, SecurityLayer la protezione del trasporto, con i valori 0 per il vecchio livello di sicurezza RDP, 1 per la negoziazione e 2 per il TLS forzato.

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer

Il vicolo cieco tipico: qualcuno disattiva NLA perché sospetta un problema di certificato, ma lascia SecurityLayer su 2. Così resta in piedi la negoziazione TLS con il certificato rotto, e l'errore cambia solo nel testo. Se per diagnosticare vuoi davvero abbassare entrambi, abbassali entrambi e poi ripristinali.

(Get-CimInstance -Namespace root\cimv2\terminalservices -ClassName Win32_TSGeneralSetting -Filter "TerminalName='RDP-tcp'") | Invoke-CimMethod -MethodName SetUserAuthenticationRequired -Arguments @{UserAuthenticationRequired=0}

Il secondo vicolo cieco è ancora più sgradevole: imposti il valore di registro, riavvii e quello torna su 1. In quel caso arriva da un criterio di gruppo. I valori dei criteri si trovano in un'altra posizione e vincono sempre:

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v UserAuthentication

gpresult /r /scope:computer

Finché lì c'è un valore, ogni modifica locale vale solo fino alla successiva applicazione dei criteri. Il criterio si chiama "Richiedi l'autenticazione utente per l'accesso remoto tramite Autenticazione a livello di rete" e va modificato sul controller di dominio.

E la regola più importante alla fine di questa sezione: disattivare NLA in modo permanente non è una soluzione, è una porta aperta. Senza NLA chiunque raggiunga la porta può arrivare alla schermata di accesso e quindi a una parte non protetta dello stack di sessione. Disattivalo per la diagnosi e riattivalo subito dopo.

Causa 5: relazione di trust del dominio interrotta

Ogni account computer in un dominio ha una password propria, che per impostazione predefinita viene cambiata automaticamente ogni 30 giorni. Se lo stato del server e quello del controller di dominio non coincidono più, il server non riesce più ad autenticare gli account di dominio, e NLA fallisce per tutti gli utenti di dominio mentre gli account locali continuano a funzionare. È proprio questo schema a dimostrare questa causa.

L'innesco classico in esercizio è il ripristino a uno stato precedente, per esempio da un backup o da uno snapshot più vecchio dell'ultimo cambio di password. Verifica:

Test-ComputerSecureChannel -Verbose

nltest /sc_verify:miodominio.local

Riparazione, con accesso come amministratore locale dalla console:

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Reset-ComputerMachinePassword -Credential (Get-Credential)

Non serve rimuovere il server dal dominio e riaggiungerlo, anzi spesso la cosa peggiora, perché così si possono perdere appartenenze a gruppi e permessi del vecchio account computer. Dopo la riparazione basta riavviare il servizio Netlogon:

Restart-Service Netlogon

Quando RDP non funziona più: la via della console

Tutti i comandi visti finora presuppongono che tu riesca in qualche modo ad arrivare al server. Nell'emergenza è proprio quello che manca. Con i server root KVM di KernelHost trovi quindi nell'area clienti una console VNC che funziona indipendentemente da RDP, dal firewall di Windows e perfino dallo stack di rete del sistema guest. È l'accesso di emergenza con cui ti tiri fuori da solo da ognuna delle situazioni descritte sopra. Sui server dedicati l'accesso di emergenza passa dal supporto.

Tre cose che sulla console VNC funzionano diversamente rispetto a una sessione RDP e che fanno regolarmente perdere tempo:

• Layout di tastiera. La console propone spesso un layout US mentre Windows è impostato su italiano, o viceversa. I caratteri speciali delle password finiscono così sbagliati e credi che una password corretta sia errata. Nel dubbio usa la tastiera su schermo con osk.exe direttamente dalla schermata di accesso.
• Appunti. Copiare dal proprio computer alla console di solito non funziona. Metti in conto di dover digitare a mano e scegli le password temporanee di conseguenza.
• Accesso come account locale. Con problemi di dominio accedi con .\Administrator, dove il punto e la barra rovesciata forzano l'account locale al posto di quello di dominio.

Sulla console verifica poi le basi, prima di mettere mano a NLA:

sc query TermService

netstat -ano | findstr :3389

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections

Se fDenyTSConnections è su 1, le connessioni remote sono del tutto disattivate, indipendentemente da NLA:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

Le regole del firewall le attivi in modo indipendente dalla lingua tramite l'identificativo interno del gruppo, perché il nome visualizzato cambia a seconda della lingua di sistema:

Enable-NetFirewallRule -Group "@FirewallAPI.dll,-28752"

Il caso particolare CredSSP, spesso confuso

Se il messaggio recita letteralmente "La funzione richiesta non è supportata" e cita la correzione dell'oracolo di crittografia CredSSP, allora nessuna delle cinque cause qui sopra è responsabile. Qui non coincidono i livelli di patch di client e server: un lato pretende la variante CredSSP rafforzata, l'altro non la conosce ancora.

L'unica soluzione pulita è aggiornare entrambi i lati. La modifica al registro che circola in rete con AllowEncryptionOracle sul client disattiva proprio l'irrigidimento che causa l'errore e riapre così una via d'attacco nota. Se ti serve a breve termine per installare gli aggiornamenti, riportala allo stato iniziale non appena il server è aggiornato.

Come capisci che il problema è davvero risolto

Una connessione riuscita è la prova più debole, perché funziona anche quando hai disattivato NLA per la diagnosi. Verifica invece nell'ordine:

1. NLA è di nuovo attivo. UserAuthentication è su 1 e SecurityLayer su 2.
2. L'orologio è corretto. Lo scostamento dello stripchart è sotto un secondo, e w32tm /query /source indica una sorgente reale, non "Local CMOS Clock" e non "Free-running System Clock".
3. Il certificato è valido. NotAfter è nel futuro, e l'hash associato punta esattamente a quel certificato.
4. Il registro eventi conferma l'autenticazione di rete superata. L'evento 1149 compare solo dopo che NLA è stato completato, quindi è la prova vera e propria.

Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational" -MaxEvents 20 | Where-Object Id -eq 1149

Per la controprova sui tentativi falliti, i codici di stato nell'evento 4625 dicono più di qualsiasi messaggio del client: 0xC0000071 indica una password scaduta, 0xC0000072 un account disattivato, 0xC0000234 un account bloccato e 0xC000006A una password davvero sbagliata.

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 5 | Format-List TimeCreated, Message

Per finire le sessioni stesse, volendo anche dalla console:

qwinsta

Confronto rapido per la ricerca dell'errore

Se stai installando da zero un server Windows, conviene impostare subito sorgente oraria, criteri degli account e via di accesso, invece di ripararli più tardi sotto pressione. Come orientamento va bene la checklist per il nuovo server root, e chi vuole proteggere ulteriormente l'accesso RDP trova in Cambiare la porta RDP senza riavvio il primo passo meno oneroso contro i tentativi di accesso automatizzati.