L'errore "interno" del desktop remoto si connette dopo l'installazione delle patch "NSA"

Ho appena installato l'ultimo aggiornamento di Windows (patch di vulnerabilità NSA martedì) e ora non riesco a collegarmi al desktop remoto.

• Il server è ospitato in remoto. Non ho accesso fisico. Server 2012 R1.
• Fortunatamente tutti i siti web funzionano correttamente dopo il riavvio.
• Non ho ancora provato un secondo riavvio perché ho un po 'paura.
• Quando provo a connettermi ricevo immediatamente questo messaggio:
• " Connessione desktop remoto : si è verificato un errore interno"

• Ho provato da più clienti. Tutti falliscono, inclusa un'app iOS che mi dà inoltre un errore 0x00000904.
• Se corro telnet servername 3389, avvia una connessione, quindi so che la porta è aperta.
• Posso connettermi bene ad altri server dalla mia macchina Win 10 (senza patch).
• Non riesco nemmeno a collegarmi dal mio secondo laptop, che è Win 10 Creators Edition.
• Impossibile trovare qualcosa di utile nel Visualizzatore eventi.
• Ho anche provato a WireShark che non mi ha mostrato nulla di utile.
• La migliore che devo diagnosticare è la possibilità di caricare una pagina ASPX ed eseguirla.

Capisco che il recente roundup di "NSA edition" ha avuto alcune correzioni RDP - ma non riesco a trovare nessun altro che improvvisamente ha avuto problemi durante la settimana.

Voglio avere un'idea di quale sia il problema prima di contattare la società di hosting, motivo per cui sto postando qui.

Aggiornare:

Anche se non ho ancora accesso fisico al server, mi sono ricordato di avere una VM Windows 7 ospitata sul server stesso. Sono stato in grado di entrare in questo e aprire lo snap-in dei certificati del server collegandomi all'IP locale 10.0.0.1.

Ciò sta dimostrando che il certificato RDP è effettivamente scaduto, anche se non ricevo errori quando si collega tale suggerimento come tale. Mi sono sicuramente connesso quotidianamente e da quando è scaduto 2 mesi fa la mia ipotesi è che un qualche tipo di aggiornamento per la sicurezza abbia rimosso qualsiasi altro certificato si trovasse nell'archivio di Desktop remoto e non si rinnovasse.

Quindi, cercando di capire un modo per installare un certificato diverso qui ora.

Aggiornamento 2

Alla fine l'ho trovato nel registro eventi in "Eventi amministrativi" (connettendosi in remoto tramite la macchina virtuale):

"Terminal Server non è riuscito a creare un nuovo certificato autofirmato da utilizzare per l'autenticazione Terminal Server su connessioni SSL. Il codice di stato rilevante era Oggetto già esistente."

Questo sembra utile, anche se un errore leggermente diverso. Non è possibile riavviare stasera, quindi dovremo ricontrollare domani.

https://blogs.technet.microsoft.com/the_9z_by_chris_davis/2014/02/20/event-id-1057-the-terminal-server-has-failed-to-create-a-new-self-signed-certificate/

La soluzione è praticamente qui

https://blogs.technet.microsoft.com/askpfeplat/2017/02/01/removing-self-signed-rdp-certificates/

Anche questo ha aiutato:

https://social.technet.microsoft.com/Forums/ie/en-US/a9c734c1-4e68-4f45-be46-8cae44c95257/unable-to-remote-desktop-to-windows-server-2012-due-to- failed-to-creare-self-signed-certificato? forum = winserverTS

Supponendo di aver già verificato che il certificato elencato in Certificati> Desktop remoto> Certificati non è valido ...

Nota: ho preso questo screenshot dopo aver risolto tutto, quindi questa data di scadenza è il certificato appena creato che ha fatto tutto da solo.

Fondamentalmente è quindi necessario rinominare o eliminare questo file e quindi lo ricrea:

"C: \ ProgramData \ Microsoft \ Crypto \ RSA \ MachineKeys \ f686aace6942fb7f7ceb231212eef4a4_a54b3870-f13c-44bb-98c7-d0511f3e1757"

Questo è un nome di file noto che inizia in f686aace. Quindi riavviare il Remote Desktop Configurationservizio e dovrebbe ricrearlo. (Nota: in realtà potrebbe non essere necessario riavviare il servizio - attendi solo per vedere se viene ricreato con lo stesso nome file per un minuto).

Potrebbero essere necessari alcuni scherzi con le autorizzazioni e potrebbe essere necessario assumere la proprietà del file e quindi applicare le autorizzazioni. Nota: la proprietà non implica autorizzazioni. È necessario aggiungere autorizzazioni dopo aver acquisito la proprietà.

Come ho detto, non ho accesso fisico al server - se lo fai, è sufficiente quanto sopra.

Ho avuto la fortuna di essere in grado di connettermi in remoto tramite un'altra macchina sulla stessa rete locale e modificare il registro.

Volevo DISATTIVARE l'autenticazione in modo da poter connettermi e ottenere l'accesso in remoto. Le voci di registro per farlo sonoHKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Impostare le chiavi esistenti SecurityLayere UserAuthenticationsu0

Crea un file RDP (apri mstsc e fai clic su Salva dopo aver inserito il nomeserver) e nel blocco note aggiungi la linea enablecredsspsupport:i:0da qualche parte. Ciò disabilita le aspettative di sicurezza.

Quando si esegue quindi il file RDP, dovrebbe consentire di connettersi in modo NON SICURO e ottenere l'accesso al proprio server.

Non appena ti connetti, modifica queste due voci di registro e poi vai avanti ed elimina il f686...file ...

Queste impostazioni hanno risolto il mio problema:

1. Nel Pannello di controllo, fare clic su Strumenti di amministrazione, quindi fare doppio clic su Criteri di sicurezza locali.

2.In Impostazioni di sicurezza locali, espandere Criteri locali e quindi fare clic su Opzioni di sicurezza.

3.In Criterio nel riquadro di destra, fare doppio clic su Crittografia di sistema: utilizzare algoritmi conformi a FIPS per crittografia, hash e firma, quindi fare clic su Abilitato. Nel mio caso è stato disabilitato. Quindi l'ho appena abilitato ed ho emesso il comando elencato di seguito.

4. Esegui gpupdate / force

Un'altra opzione che risolverà questo problema:

I protocolli non sono stati abilitati sul server. Ho usato IIScrypto e abilitato TLS1.2 e tutto ha iniziato a funzionare

Ciao a tutti nel mio ambiente, ciò è stato causato quando è stato generato un nuovo certificato autofirmato TLS 1.0 è disabilitato nel registro o non esiste nel registro e il nuovo certificato autofirmato non si trovava nell'archivio delle autorità di certificazione radice attendibili.

Puoi provare questo in due modi prima di modificare il registro. scarica IIS Crypto e vedi cosa è abilitato e disabilitato in Protocolli, Cifre, Hash e Scambi chiave.

A volte però IIS Crypto mostrerà che TLS è abilitato anche se non è abilitato nel registro solo in una FYI.

L'opzione successiva è di attivare FIPS in Criteri di gruppo locali per forzare l'attivazione e l'utilizzo di TLS 1.0, 1.1 e 1.2. Attiva FIPS e quindi prova a utilizzare RDP sul tuo computer, questa volta funzionerà anche se TLS è disabilitato nel registro. Non vuoi usare FIPS in modo permanente anche se questo è solo per la risoluzione dei problemi, quindi disabilitalo sul server e vai al registro.

Testa a HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNELe sotto protocolli aggiungere tre nuove chiavi titolo di loro TLS 1.0, TLS 1.1e TLS 1.2quindi creare due tasti sotto sotto ogni voce Titolo TLS loro Cliente Server.

All'interno dei tasti Cliente Servercreare due voci DWORD a 32 bit una intitolata DisabledByDefaultcon il Valueset su 0 e Enabledcon il valore impostato su 1.

Una volta fatto questo e il tuo certificato autofirmato non è scaduto e nei negozi corretti sarai di nuovo in grado di eseguire il RDP nel tuo server.