1 12/10/2026 7 min

CredSSP: quando l’errore non è il RDP ma l’autenticazione delegata

L’errore CredSSP compare quasi sempre durante una connessione RDP con il messaggio che segnala un problema di encryption oracle remediation oppure con un blocco generico dell’autenticazione. In pratica la sessione remota non fallisce per il trasporto, ma nel punto in cui il client e il server devono negoziare in modo sicuro l’uso delle credenziali dell’utente.

Su Windows Server 2019 e 2022 il problema nasce spesso da un disallineamento tra patch, policy di sicurezza o impostazioni locali/GPO. Il caso classico è semplice: un client aggiornato tenta di collegarsi a un server più vecchio o configurato con criteri troppo permissivi; meno spesso succede il contrario, cioè il client è bloccato da una policy troppo rigida rispetto al sistema remoto.

La correzione giusta non è “abbassare tutto” a caso. Prima si identifica il layer coinvolto, poi si decide se intervenire sul client, sul server o sul criterio di dominio. Se si tocca la policy, va considerato il blast radius: CredSSP impatta ogni sessione RDP che usa autenticazione a livello di rete, non solo l’utente che sta aprendo il ticket.

Come riconoscere il sintomo corretto

Il messaggio più noto è quello che cita esplicitamente CredSSP o l’encryption oracle remediation. In altri casi la finestra RDP mostra un errore più vago, ma nei log compaiono eventi di autenticazione fallita o di negoziazione TLS/SSPI interrotta. Se il problema fosse DNS, porta chiusa o firewall, il fallimento avverrebbe prima, con timeout o impossibilità di raggiungere l’host.

La distinzione utile è questa: se il server risponde su 3389 ma la sessione si interrompe subito dopo l’inserimento delle credenziali, il sospetto CredSSP è alto. Se invece non c’è proprio handshake RDP, il problema è altrove e forzare una modifica CredSSP non serve a nulla.

Verifica iniziale: client, server o dominio

Prima di cambiare policy, conviene capire dove sta il disallineamento. La verifica minima è questa:

1. Controlla il client
Da una macchina Windows coinvolta apri gpedit.msc oppure verifica la policy con:

gpresult /h C:\Temp\gp.html

Nel report cerca la voce relativa a Encryption Oracle Remediation sotto i criteri di sistema/CredSSP. Se la policy è applicata da dominio, la modifica locale non basta.

2. Verifica il server
Sul server Windows Server 2019/2022 controlla se esiste una policy locale o di dominio che impone un livello incompatibile. La chiave di registro utile, quando presente, è sotto:

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters

Il valore più importante è AllowEncryptionOracle. Se è assente, la macchina segue il comportamento predefinito o quello imposto da GPO; se è presente, va letto nel contesto della policy applicata.

3. Cerca eventi nei log
Apri Event Viewer e controlla Applications and Services Logs > Microsoft > Windows > CredSSP > Operational, se abilitato, oltre ai log di sicurezza e sistema. La presenza di errori in quell’area aiuta a distinguere un problema di compatibilità da un semplice blocco di rete.

Correzione consigliata: allineare prima il livello di sicurezza

La strada corretta è portare client e server allo stesso livello di patch e lasciare che la protezione resti attiva. Microsoft ha introdotto la mitigazione per prevenire vulnerabilità nella negoziazione CredSSP; quindi la soluzione strutturale è aggiornare entrambi gli estremi, non disattivare il controllo in modo permanente.

Se il server è vecchio o non aggiornabile subito, si può applicare una mitigazione temporanea lato client o server, ma va trattata come eccezione a tempo. In un ambiente di dominio, meglio farlo con GPO mirata e con finestra di rollback già pronta.

Procedura pratica: verificare e correggere senza esporre troppo

1. Aggiorna Windows
Su client e server applica gli ultimi aggiornamenti cumulativi disponibili. Dopo il riavvio, riprova la connessione RDP. Se il problema era solo un disallineamento di build o patch, spesso sparisce senza altri interventi.

2. Verifica la policy di gruppo
Su un host amministrativo apri gpedit.msc e vai in:

Computer Configuration > Administrative Templates > System > Credentials Delegation

La voce da controllare è Encryption Oracle Remediation. In ambienti moderni il valore corretto è quello più restrittivo compatibile con la tua infrastruttura. Se devi sbloccare temporaneamente un client legacy, usa il livello meno invasivo solo per il tempo strettamente necessario.

3. Se serve una mitigazione temporanea lato client
Su una macchina di test o su un client amministrativo, puoi applicare il valore via registro per verificare l’effetto:

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

Questo è il classico intervento di compatibilità, non la destinazione finale. Dopo il test, la verifica deve essere immediata: se RDP riparte, hai confermato che il problema è la negoziazione CredSSP e non un guasto generico del servizio Terminal Services.

4. Se l’host remoto è il collo di bottiglia
Quando il server è gestito da un team diverso o è un appliance/VM con patching lento, conviene intervenire sul client solo come misura transitoria. In un ambiente di dominio, la correzione pulita è una GPO dedicata, documentata e con scadenza operativa, non una modifica manuale sparsa su singole workstation.

Correzione via Group Policy: il caso enterprise

Se il problema interessa più host, la GPO è la via giusta. In questo modo eviti configurazioni divergenti e riduci il rischio di lasciare client “sistemati” a metà. La policy va applicata solo al gruppo interessato, non a tutto il dominio se non serve.

Nel percorso Computer Configuration > Administrative Templates > System > Credentials Delegation imposta Encryption Oracle Remediation secondo il livello richiesto dal tuo scenario. Se stai facendo una deroga temporanea, annota la data di scadenza e il motivo tecnico nel change record.

Per chi lavora con GPO è utile verificare l’effetto con:

gpupdate /force
rsop.msc

Il primo forza l’applicazione, il secondo aiuta a vedere quale criterio è davvero in vigore sul computer target.

Quando non devi abbassare la protezione

Disabilitare in modo permanente la protezione CredSSP è una scelta debole, soprattutto se il server è esposto a utenti amministrativi o jump host condivisi. Il rischio non è teorico: stai abbassando il livello di difesa proprio nel punto in cui vengono maneggiate credenziali e sessioni remote privilegiate.

Se l’ambiente è sotto controllo, il percorso migliore è questo: correggere patch, verificare la versione di Windows, allineare la policy, testare la sessione e poi tornare alla configurazione più restrittiva possibile. La deroga va trattata come un ponte, non come uno stato stabile.

Check finale: come capire che il fix è davvero andato a buon fine

Dopo la correzione, la verifica non deve limitarsi a “RDP si apre”. Serve controllare che la connessione usi ancora l’autenticazione desiderata e che non compaiano nuovi warning nei log.

Checklist minima:

  • RDP si connette senza errore CredSSP.
  • Event Viewer non mostra errori ricorrenti in CredSSP/Operational.
  • La policy applicata è quella prevista da gpresult /h o rsop.msc.
  • Se hai usato una deroga temporanea, il valore di registro o la GPO è tornato al livello corretto.

Se il problema persiste dopo gli update e la policy è coerente, il passo successivo è cercare cause correlate: mismatch di ora di sistema, canali RDP alterati da gateway o VPN, configurazioni NLA incoerenti, oppure un server che risponde ma ha componenti di sicurezza danneggiati.

Rollback pulito della mitigazione temporanea

Se hai applicato la mitigazione via registro per sbloccare un accesso urgente, il rollback deve essere esplicito. Rimuovi il valore o riallinealo alla policy definitiva, poi rilancia il refresh dei criteri.

reg delete HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters /v AllowEncryptionOracle /f
gpupdate /force

Se la modifica è stata fatta via GPO, annulla o modifica il criterio dal controller di dominio, non solo sul singolo server. In caso di dubbio, esporta la configurazione prima del cambio e conserva il riferimento del valore precedente nel ticket o nel change plan.

Assunzione operativa: qui si presuppone un ambiente Windows Server 2019/2022 con RDP abilitato, policy gestite localmente o via dominio, e accesso amministrativo per verificare log e criteri.