Connessione RDP a Windows Server 2016 Essentials da remoto: errore “logon attempt failed” – cause e soluzioni

Errore “logon attempt failed” nella connessione RDP a Windows Server 2016 Essentials da Internet? In questa guida pratica spieghiamo come individuarne la causa reale (RD Gateway, NLA/Kerberos, certificati, porte, DNS) e come risolvere in modo sicuro e duraturo.

Indice

Scenario e sintomi

Dopo anni di funzionamento regolare, l’accesso RDP dall’esterno smette improvvisamente di funzionare con il messaggio “logon attempt failed”. Le stesse credenziali di dominio (ad es. Administrator) continuano invece a funzionare:

alla console locale del server;
da un PC interno in LAN via RDP;
nei log dell’infrastruttura compare che Remote Desktop Gateway (RDG) accetta la richiesta.

Conclusione: il rifiuto avviene nella fase di autenticazione al server di destinazione, dopo il passaggio dal Gateway. Le cause più frequenti sono: certificato RDG scaduto o mal legato, problemi NLA/CredSSP/Kerberos (SPN, DNS, orologio), policy CAP/RAP, DNS pubblico non aggiornato, oppure blocchi su porte.

Come funziona l’accesso remoto in Windows Server 2016 Essentials

Essentials abilita la funzionalità Anywhere Access e usa tipicamente un RD Gateway locale. I client si connettono all’FQDN pubblico del server (o del gateway) sulla porta TCP 443 (HTTPS). Il Gateway autentica e autorizza (CAP/RAP) e poi “instrada” la sessione verso la destinazione RDP interna (di solito lo stesso server), che accetta sulla TCP 3389. Se è abilitata la Network Level Authentication (NLA), il client deve autenticarsi prima di iniziare la sessione grafica. Qualunque problema legato a certificati, SPN, tempo o protocolli può quindi impedire la negoziazione e generare l’errore.

Percorso decisionale rapido

Connettività: la porta giusta è aperta? Con RDG serve 443 dall’esterno; senza RDG serve 3389.
RD Gateway: servizio attivo, certificato TLS valido e correttamente associato; CAP/RAP coerenti; DNS pubblico aggiornato.
NLA: disattivalo temporaneamente per diagnosticare. Se così funziona dall’esterno, indaga su Kerberos/SPN/clock/CredSSP.
Log: controlla Security (ID 4625) e TerminalServices-Gateway/Operational per un motivo preciso del rifiuto.
Client: ripulisci credenziali memorizzate, aggiorna il client, prova una rete diversa (hotspot).

Tabella di controllo: dove guardare e cosa fare

Area da verificare	Dettagli operativi
Connettività e porte	NAT/Firewall: • senza RD Gateway: aprire TCP 3389 verso il server. • con RD Gateway (tipico in Essentials): esporre TCP 443 verso il server. Test rapidi: `Test-NetConnection gateway.dominio.it -Port 443 Test-NetConnection server.lan.local -Port 3389 in emergenza: telnet gateway.dominio.it 443`
RD Gateway	Servizi: Remote Desktop Gateway, Network Policy Server, World Wide Web Publishing in esecuzione. Certificato TLS: non scaduto, catena completa, FQDN corrispondente all’host pubblicato, corretta associazione al Gateway. CAP/RAP: l’utente/gruppo è autorizzato ad accedere e a raggiungere la risorsa destinazione. DNS pubblico: record A/CNAME aggiornato se l’IP WAN è cambiato.
Network Level Authentication (NLA)	In Sistema → Impostazioni di connessione remota, togli temporaneamente “Consenti solo connessioni… con NLA”. Se da Internet ora funziona, la causa è nella catena NLA/CredSSP/Kerberos (SPN, clock skew, restrizioni NTLM).
Log e account	Event Viewer → Security: Event ID 4625 con substatus `0xC000006A` (password errata), `0xC000006D` (info credenziali invalide), `0xC000006F` (orari non consentiti), `0xC0000234` (account bloccato), `0xC0000072` (account disabilitato). TerminalServices‑Gateway/Operational: conferma di CAP/RAP “Allowed” oppure motivi di “Denied”. Verifica che l’account non sia scaduto o bloccato e sia membro di Remote Desktop Users.
Firewall di Windows	Abilita le regole “Remote Desktop (TCP‑In)” per profili Domain e Public.
Client RDP	Cancella le credenziali salvate in Gestione credenziali Windows. Aggiorna il client RDP; prova da rete cellulare per escludere filtri del proprio ISP.

Diagnosi guidata e comandi utili

Verifica rapida del certificato del RD Gateway

Apri MMC → Certificates (Local Computer) → Personal → Certificates e controlla Subject e NotAfter. In PowerShell:

Get-ChildItem Cert:\LocalMachine\My |
  Sort-Object NotAfter -Descending |
  Select-Object Subject, NotAfter, Thumbprint |
  Format-Table -Auto

Se il certificato è scaduto, rinnovalo e associa la nuova Thumbprint al RD Gateway (RD Gateway Manager → Proprietà → SSL Certificate). Verifica anche l’associazione HTTP:

netsh http show sslcert ipport=0.0.0.0:443

Controllo CAP/RAP

In RD Gateway Manager verifica che:

la Connection Authorization Policy (CAP) includa l’utente o il gruppo corretto;
la Resource Authorization Policy (RAP) includa il server di destinazione (nome o gruppo di computer) e la porta 3389.

Test con NLA disattivata (solo per diagnosi)

Disabilita NLA (Sistema → Impostazioni di connessione remota) oppure via GPO:

# GPO locale
gpedit.msc
Percorso:
Configurazione computer → Modelli amministrativi → Servizi Desktop remoto
→ Host sessione Desktop remoto → Sicurezza → Richiedi autenticazione utente con NLA (Disabilitato)

Riprova da Internet. Se l’accesso ora funziona, investiga le seguenti aree.

Se è NLA: cosa controllare in profondità

DNS, SPN e corrispondenza nomi

Kerberos richiede corrispondenza tra il nome usato dal client e gli SPN del server. Per RDP l’SPN è TERMSRV/<nome>. Se il client usa un alias o un FQDN esterno non presente tra gli SPN del computer di destinazione, l’autenticazione può fallire (specie con restrizioni NTLM).

# Elenca gli SPN registrati per il server
setspn -L NOME-SERVER

Aggiungi un SPN mancante per il FQDN interno o esterno

setspn -S TERMSRV/server.lan.local NOME-SERVER
setspn -S TERMSRV/server.dominio.it NOME-SERVER

Attenzione: aggiungi solo SPN pertinenti e reali; evita duplicati su macchine diverse. Dopo la modifica, aggiorna la replica AD e prova di nuovo.

Sincronizzazione oraria (clock skew)

Kerberos è sensibile allo scarto orario. Più di 5 minuti possono provocare errori di logon. Sul server:

w32tm /query /status
w32tm /query /peers
w32tm /resync

Assicurati che tutti i membri del dominio (server e client) siano allineati alla stessa fonte affidabile.

Restrizioni NTLM e fallback

Se Kerberos non è possibile, alcuni ambienti consentono il fallback NTLM. Policy che “limitano NTLM” possono però bloccarlo: in tal caso è indispensabile che Kerberos+SPN funzioni. Verifica le policy di sicurezza che limitano NTLM e allineale al requisito minimo dell’organizzazione.

CredSSP ed “Encryption Oracle Remediation”

Mancate corrispondenze tra patch di client e server o una policy troppo restrittiva su CredSSP possono rompere NLA. Per test rapido (temporaneo e solo in ambienti controllati):

# Criteri di gruppo locali:
Configurazione computer → Modelli amministrativi → Sistema → Delegazione delle credenziali
→ Correzione dell'oracolo di crittografia (Imposta su "Mitigated" o "Vulnerable" per test)

Oppure via registro (riavvio del servizio RDP):

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters ^
/v AllowEncryptionOracle /t REG_DWORD /d 2 /f

Se così funziona, aggiorna server e client e riporta la policy a un livello sicuro.

Log che parlano chiaro: cosa leggere e come interpretarli

Security → Event ID 4625: guarda Failure Reason e Status/SubStatus.
- 0xC000006A: password errata (verifica tastiera/IME, blocco Caps).
- 0xC000006D: credenziali invalide (SPN/realm errato, NLA/NTLM).
- 0xC000006F: logon fuori dagli orari consentiti (controlla Logon Hours).
- 0xC0000234: account bloccato.
- 0xC0000072: account disabilitato o scaduto.
Applications and Services Logs → Microsoft → Windows → TerminalServices‑Gateway → Operational:
- Eventi “CAP authorization succeeded/failed” e “RAP authorization succeeded/failed”. Se CAP/RAP sono “succeeded” ma il client riceve “logon attempt failed”, focalizzati su NLA/host di destinazione.
Schannel (se handshake TLS fallisce): verifica problemi di protocollo/cipher.

Puoi estrarre rapidamente dal registro con:

wevtutil qe Security /q:"*[System[(EventID=4625)]]" /f:text /c:10
wevtutil qe "Microsoft-Windows-TerminalServices-Gateway/Operational" /f:text /c:20

Firewall di Windows e profili di rete

In scenari Essentials, il traffico dal RDG verso l’RDP locale avviene comunque su 3389. Controlla che le regole “Remote Desktop (TCP‑In)” siano abilitate per Domain e Public (può tornare utile in casi di rilevazione errata del profilo di rete o migrazioni di schede).

Get-NetFirewallRule -DisplayGroup "Remote Desktop" |
  Select-Object DisplayName, Enabled, Profile |
  Format-Table -Auto

Fattori lato client RDP

Credenziali memorizzate: apri Gestione credenziali e rimuovi le voci legate a TERMSRV/<server> o all’FQDN esterno.
Versione client: usa un client aggiornato (MSTSC o app Microsoft Remote Desktop).
Rete diversa: prova da hotspot mobile per escludere filtri dell’ISP (Geo/IP reputation, blocchi 3389, DPI su TLS/443).
Switch /admin: in diagnosi, prova mstsc /admin per evitare limiti di sessione.

Wizard “Anywhere Access” e “Fix My Network”

Windows Server 2016 Essentials offre una procedura guidata che ripara automaticamente diversi elementi (certificati, binding HTTPS, regole firewall, NAT UPnP, RDG):

Apri Dashboard di Essentials.
Vai in Home → Setup → Set up Anywhere Access.
Usa Fix My Network per rigenerare/associare il certificato, riaprire porte e riallineare il DNS pubblico.

Dopo l’operazione, ripeti i test di connettività e verifica che il Gateway presenti il nuovo certificato ai client.

Valutare una VPN SSTP in Essentials

Per ridurre l’esposizione di RDP, valuta l’uso della VPN SSTP integrata (porta 443). Il flusso consigliato:

Connessione VPN al server Essentials (autenticazione utente, eventualmente con MFA).
Una volta “dentro”, lancia RDP verso l’IP interno o FQDN del server (NLA attiva).

Vantaggi: superficie d’attacco minore, separazione tra autenticazione esterna e RDP, migliore controllo su policy e logging.

Sicurezza operativa: buone pratiche

MFA: abilita un secondo fattore sull’accesso remoto (gateway o VPN).
Principio del privilegio minimo: non usare l’account Administrator per l’accesso quotidiano; crea un utente standard abilitato all’RDP e usa l’elevazione solo quando serve.
Patch: mantieni aggiornati server e client (RDP, CredSSP, TLS, .NET).
Audit: abilita log dettagliati sul Gateway e sul server; monitora tentativi ripetuti (possibile brute force).

Script diagnostico “tutto in uno” (PowerShell)

Esegui come amministratore sul server Essentials per una fotografia rapida di stato:

$gatewayFqdn = "gateway.dominio.it"
$serverFqdn  = "server.lan.local"

Write-Host "== Porte esterne ==" -ForegroundColor Cyan
Test-NetConnection $gatewayFqdn -Port 443 | Format-List

Write-Host "== Porte interne ==" -ForegroundColor Cyan
Test-NetConnection $serverFqdn -Port 3389 | Format-List

Write-Host "== Servizi RDG/NPS/IIS ==" -ForegroundColor Cyan
"TSGateway","IAS","W3SVC" | ForEach-Object { Get-Service $_ }

Write-Host "== Certificati personali (Top 3) ==" -ForegroundColor Cyan
Get-ChildItem Cert:\LocalMachine\My |
Sort-Object NotAfter -Descending |
Select-Object -First 3 Subject,NotAfter,Thumbprint |
Format-Table -Auto

Write-Host "== Binding SSL su 0.0.0.0:443 ==" -ForegroundColor Cyan
netsh http show sslcert ipport=0.0.0.0:443

Write-Host "== SPN TERMSRV del server ==" -ForegroundColor Cyan
setspn -L $env:COMPUTERNAME

Write-Host "== Stato orologio ==" -ForegroundColor Cyan
w32tm /query /status

Write-Host "== Regole Firewall RDP ==" -ForegroundColor Cyan
Get-NetFirewallRule -DisplayGroup "Remote Desktop" |
Select-Object DisplayName, Enabled, Profile |
Format-Table -Auto

Write-Host "== Ultimi 10 4625 (Security) ==" -ForegroundColor Cyan
wevtutil qe Security /q:"*[System[(EventID=4625)]]" /f:text /c:10

Analizza ogni sezione: se vedi un certificato scaduto, un binding mancante, SPN incompleti o clock skew, hai trovato una causa plausibile.

Edge case da non trascurare

Record DNS pubblico puntato al vecchio IP: RDG accetta in locale ma il client non raggiunge l’host giusto. Aggiorna il record (o verifica il servizio DDNS se usato).
Port forwarding duplicato sul router: più mapping 443 → host differenti può causare instabilità.
Dispositivi UTM/WAF: ispezione TLS aggressiva può rompere l’handshake del RDG. Escludi l’FQDN del gateway da SSL inspection.
Limite sessioni: su Essentials restano due sessioni amministrative. Se bloccate, libera con: qwinsta rwinsta <ID-sessione> # attenzione: disconnette l'utente indicato
Policy “Deny log on through RDS”: un hardening eccessivo può negare l’accesso a gruppi legittimi. Verifica le GPO di dominio.
Protocolli TLS disabilitati: se è rimasto attivo solo TLS 1.0/1.1 o, al contrario, solo 1.2 con cipher inadeguati, alcuni client falliscono. Mantieni TLS 1.2 attivo con una suite moderna e compatibile.

Procedura operativa consigliata (passo passo)

Certificato RD Gateway: in MMC verifica scadenza e Subject; se necessario rinnova e riassocia in RD Gateway Manager. Controlla la catena (intermediate) e il binding 0.0.0.0:443.
Disattiva NLA temporaneamente e rifai la prova dall’esterno.
- Se funziona: è NLA → sistema SPN (TERMSRV/…), DNS e sincronizzazione oraria; verifica policy NTLM e CredSSP.
- Se non funziona: non è NLA → torna su rete/porte, CAP/RAP, certificato, ispezione SSL.
Log di sicurezza: individua il substatus esatto del 4625. Ogni codice indirizza a una causa specifica (password, orari, lockout, trust).
Prova da rete diversa: usa un hotspot per escludere filtri del provider o reputazione IP geografica.

Esempi di correzioni dal mondo reale

Certificato scaduto sul RDG: il client RDP non si fidava del canale TLS, handshake fallito. Rinnovo, importazione della catena intermedi, nuova associazione al Gateway → tutto ok.
SPN mancante “TERMSRV/server.dominio.it”: l’azienda si connetteva con un alias esterno. Aggiunta SPN sul computer, replica AD, NLA tornata operativa.
Clock skew di 8 minuti dopo un fermo: w32tm /resync su PDC e client, ripartenza Kerberos immediata.
CAP corretta ma RAP errata: utente autorizzato ad accedere al Gateway, ma la risorsa non inclusa nella RAP. Aggiunto il computer all’elenco consentito → autenticazione ok.

Hardening finale (senza perdere usabilità)

Lascia NLA attiva (dopo la risoluzione).
Preferisci VPN SSTP + RDP rispetto a RDP esposto direttamente.
Abilita MFA sull’accesso remoto.
Usa account non amministrativi per collegarti; eleva quando necessario.
Riduci la superficie: consenti l’accesso RDG solo da Paesi/indirizzi IP attesi (se il firewall lo supporta).
Monitora i log con alert su 4625 ripetuti e su eventi RDG “Denied”.

Checklist di verifica post‑fix

Connessione da Internet raggiunge il Gateway su 443 (Test-NetConnection ok).
RD Gateway presenta un certificato valido e trusted dal client; FQDN corrispondente.
CAP/RAP allineate a utenti e risorse corrette.
Server di destinazione ascolta su 3389 (qwinsta mostra sessioni coerenti; netstat -an | find ":3389" in ascolto).
NLA attiva e funzionante; SPN “TERMSRV/<nome>” presenti; orologio sincronizzato.
Client aggiornati; nessuna credenziale obsoleta memorizzata.

Domande frequenti

Perché funziona in LAN ma non da Internet?
In LAN il client usa spesso il nome NetBIOS o il FQDN interno coerente con gli SPN e la risoluzione DNS. Da Internet entrano in gioco il Gateway, l’FQDN pubblico, il certificato e policy diverse (NLA, NTLM). Un disallineamento appena descritto spiega differenze di comportamento.

Il Gateway “approva”, ma ricevo “logon attempt failed”. Da dove inizio?
Parti da NLA: disabilita in test, se migliora correggi SPN/DNS/tempo/CredSSP. Se non cambia, torna al certificato del Gateway e alla RAP verso il server target.

Posso risolvere lasciando NLA disattivata?
Sconsigliato. NLA è una misura di sicurezza importante: il suo spegnimento espone il server a rischi. Usala come strumento diagnostico, non come fix definitivo.

Conclusioni

L’errore “logon attempt failed” nelle connessioni RDP a Windows Server 2016 Essentials è quasi sempre il risultato di un dettaglio che si è incrinato nel tempo: certificato scaduto, SPN non più allineati con il nome usato dal client, DNS pubblico cambiato, orologi fuori sync, o una policy RDG che non rispecchia più la realtà. Seguendo il percorso qui proposto — test porte, stato RDG e certificato, prova con NLA disattivata, lettura mirata dei log, correzione di SPN/tempo/policy — si arriva rapidamente alla causa radice e si ripristina un accesso sicuro e stabile. Per il futuro, prendi in considerazione VPN SSTP, MFA e account a privilegi minimi: meno esposizione, più controllo.

Procedura rapida consigliata (riassunto operativo)

Certificato RD Gateway: MMC → Certificates → Personal. Controlla scadenza, rinnova e riassegna al Gateway.
Disattiva NLA e riprova dall’esterno. Se va, correggi DNS/SPN o sincronizzazione oraria (Kerberos/CredSSP).
Log di sicurezza: cerca ID 4625 e interpreta lo SubStatus per avere il motivo preciso del rifiuto.
Rete alternativa: test da hotspot mobile per escludere blocchi dell’ISP o filtri geografici.

Suggerimenti aggiuntivi

Usa il wizard Anywhere Access → Fix My Network per rigenerare certificati e aprire/associare correttamente le porte.
Valuta una VPN SSTP integrata in Essentials per ridurre l’esposizione diretta di RDP.
Abilita MFA e prediligi un account non‑admin per l’RDP, elevando i privilegi solo quando necessario.