'Erro interno' da área de trabalho remota tentando conectar após a instalação dos patches da NSA

Acabei de instalar a atualização mais recente do Windows (patch de vulnerabilidade da NSA na terça-feira) e agora não consigo me conectar à área de trabalho remota.

• O servidor está hospedado remotamente. Eu não tenho acesso físico. Server 2012 R1.
• Felizmente, todos os sites estão funcionando bem após a reinicialização.
• Ainda não tentei uma segunda reinicialização porque estou com um pouco de medo.
• Quando tento conectar, recebo imediatamente esta mensagem:
• " Conexão de área de trabalho remota : ocorreu um erro interno"

• Já tentei de vários clientes. Todos eles falham - incluindo um aplicativo iOS que, além disso, gera um erro 0x00000904.
• Se eu executar telnet servername 3389, ele iniciará uma conexão, então sei que a porta está aberta.
• Posso conectar-me perfeitamente a outros servidores da minha máquina Win 10 (sem patch).
• Também não consigo me conectar a partir do meu segundo laptop, que é a edição Win 10 Creators.
• Não foi possível encontrar nada útil no Visualizador de Eventos.
• Eu até tentei o wireshark, que não me mostrou nada de útil.
• O melhor que tenho que diagnosticar é a capacidade de fazer upload de uma página ASPX e executá-la.

Entendo que o recente ajuntamento de patches da "edição da NSA" teve algumas correções no RDP - mas não consigo encontrar mais ninguém que de repente tenha problemas durante a semana.

Quero ter uma idéia de qual é o problema antes de entrar em contato com a empresa de hospedagem, e é por isso que estou postando aqui.

Atualizar:

Embora ainda não tenha acesso ao servidor físico, lembrei-me de que tenho uma VM do Windows 7 hospedada no próprio servidor. Consegui entrar nisso e abrir o snap-in de certificados do servidor conectando-me ao IP local 10.0.0.1.

Isso está mostrando que o certificado RDP realmente expirou - embora eu não receba erros ao conectar o que sugere como tal. Certamente, eu tenho me conectado diariamente e, desde que expirou, há dois meses, acho que algum tipo de atualização de segurança removeu qualquer outro certificado existente na loja da Área de Trabalho Remota e não se renovou.

Então, tentando descobrir uma maneira de instalar um certificado diferente aqui agora.

Atualização 2

Finalmente, encontrei isso no log de eventos em 'Eventos administrativos' (conectando-se remotamente via VM):

"O Terminal Server falhou ao criar um novo certificado autoassinado para ser usado na autenticação do Terminal Server em conexões SSL. O código de status relevante era Objeto já existe."

Isso parece útil, embora um erro ligeiramente diferente. Não é possível reiniciar esta noite, portanto, será necessário verificar novamente amanhã.

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/

A solução é basicamente aqui

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

Isso também ajudou:

https://social.technet.microsoft.com/Forums/ie/en-US/a9c734c1-4e68-4f45-be46-8cae44c95257/unable-to-remote-desktop-to-windows-server-2012-due-to- falha ao criar o certificado autoassinado? forum = winserverTS

Supondo que você já tenha verificado que o certificado listado em Certificados> Área de trabalho remota> Certificados não é válido ...

Nota: Tirei esta captura de tela depois de corrigir tudo - portanto, essa data de validade é o certificado recém-criado que ele fez sozinho.

Basicamente, você precisa renomear ou excluir esse arquivo - e ele será recriado:

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

Este é um nome de arquivo conhecido a partir de f686aace. Em seguida, reinicie o Remote Desktop Configurationserviço e ele deve recriá-lo. (Nota: pode não ser realmente necessário reiniciar o serviço - aguarde para ver se ele foi recriado com o mesmo nome de arquivo por um minuto).

Pode levar algum tempo para mexer nas permissões, e você pode precisar se apropriar do arquivo e aplicar permissões. Nota: A propriedade não implica permissões. Você deve adicionar permissões depois de se apropriar.

Como eu disse, não tenho acesso físico ao servidor - se você tiver, o que foi dito acima será suficiente.

Tive a sorte de poder conectar-me remotamente através de outra máquina na mesma rede local e alterar o registro.

Eu queria DESABILITAR a autenticação para poder conectar e obter acesso remotamente. As entradas do registro para fazer isso sãoHKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Defina as chaves existentes SecurityLayere UserAuthenticationpara0

Crie um arquivo RDP (abra mstsc e clique em Salvar depois de inserir o nome do servidor) e, no bloco de notas, adicione a linha em enablecredsspsupport:i:0algum lugar. Isso desativa a expectativa de segurança.

Quando você executa o arquivo RDP, ele deve permitir a conexão SEM SEGURANÇA e obter acesso ao seu servidor.

Assim que você se conectar, altere essas duas entradas do registro novamente e, em seguida, prossiga e exclua o f686...arquivo ...

Essas configurações corrigiram meu problema:

1. No Painel de controle, clique em Ferramentas administrativas e clique duas vezes em Diretiva de segurança local.

2.Em Configurações de segurança local, expanda Diretivas locais e clique em Opções de segurança.

3.Em Diretiva, no painel direito, clique duas vezes em Criptografia do sistema: use algoritmos compatíveis com FIPS para criptografia, hash e assinatura e clique em Habilitado. No meu caso, foi desativado. Então, eu apenas o habilitei e emiti o comando listado abaixo.

4. Execute gpupdate / force

Outra opção que resolverá esse problema:

Os protocolos não foram ativados no servidor. Usei o IIScrypto e habilitei o TLS1.2 e tudo começou a funcionar

Olá a todos no meu ambiente, isso foi causado quando um novo certificado autoassinado foi gerado O TLS 1.0 está desabilitado no registro ou não existe no registro e o novo certificado autoassinado não estava no armazenamento confiável das autoridades de certificação raiz.

Você pode provar isso de duas maneiras antes de editar o registro. Baixe o IIS Crypto e veja o que está ativado e desativado em Protocolos, Cifras, Hashes e Trocas de Chaves.

Às vezes, embora o IIS Crypto mostre que o TLS está ativado, mesmo que não esteja habilitado no registro apenas como um FYI.

Sua próxima opção é ativar o FIPS na política de grupo local, forçando o TLS 1.0, 1.1 e 1.2 a ser ativado e usado. Ative o FIPS e, em seguida, tente fazer o RDP em sua máquina, pois desta vez funcionará mesmo se o TLS estiver desativado no registro. Você não deseja usar o FIPS permanentemente, embora isso seja apenas para solucionar problemas, então desative-o no servidor e vá para o registro.

Dirija-se HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNELe em Protocolos adicionar três título novas chaves-los TLS 1.0, TLS 1.1e, TLS 1.2em seguida, criar duas chaves sub sob cada TLS entrada Título los Cliente Server.

Dentro das teclas Cliente, Servercrie duas entradas DWORD de 32 bits, uma DisabledByDefaultcom o título Valuedefinido como 0 e Enabledo valor definido como 1.

Depois de fazer isso e seu certificado autoassinado não expirar, e nas lojas corretas, você poderá fazer o RDP no servidor novamente.