Erro interno 'erro interno' da área de trabalho conectado após as correções 'NSA' instaladas

Question

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

• O servidor é 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.
• Eu ainda não tentei uma segunda reinicialização porque estou com um pouco de medo.
• Quando tento me conectar, imediatamente recebo esta mensagem:
• " Conexão de área de trabalho remota : ocorreu um erro interno"

• Tenteideváriosclientes.Todoselesfalham-incluindoumaplicativoparaiOSque,alémdisso,medáumerro0x00000904.
• Seeuexecutartelnetservername3389,eleiniciaráumaconexão,porissoseiqueaportaestáaberta.
• PossomeconectarmuitobemcomoutrosservidoresdaminhamáquinaWin10(sempatches).
• Tambémnãoconsigomeconectarcommeusegundolaptop,queéaediçãodoWin10Creators.
• NãoépossívelencontrarnadadeútilnoVisualizadordeEventos.
• Euatétenteiowiresharkquenãomemostrounadadeútil.
• OmelhorquetenhoparadiagnosticaréacapacidadedefazeruploaddeumapáginaASPXeexecutá-la.

Euentendoqueorecenteagrupamentodeatualizaçõesda"edição da NSA" teve algumas correções de RDP - mas não consigo encontrar ninguém que de repente tenha problemas na semana passada.

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

Atualização:

Embora eu ainda não tenha acesso ao servidor físico, lembrei 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 está realmente expirado - embora eu não tenha erros ao conectar essa sugestão como tal. Eu certamente tenho me conectado diariamente e desde que expirou há dois meses, meu palpite é que algum tipo de atualização de segurança removeu qualquer outro certificado no armazenamento da Área de Trabalho Remota e ele 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 por meio da VM):

"The Terminal Server has failed to create a new self signed certificate to be used for Terminal Server authentication on SSL connections. The relevant status code was Object already exists."

Isso parece útil, embora seja um erro ligeiramente diferente. Não é possível reiniciar hoje à noite, por isso terá que verificar novamente amanhã.

    

Answer 1

A solução é basicamente aqui

link

Isso também ajudou:

link

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

Nota:eutireiessacapturadeteladepoiseuconserteitudo-entãoessadatadeexpiraçãoéocertificadorecémcriadoqueelefezsozinho.

Vocêbasicamenteprecisarenomearouexcluirestearquivo-e,emseguida,eleserárecriado:

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

Este é um nome de arquivo conhecido que começa em f686aace . Em seguida, reinicie o serviço Remote Desktop Configuration e ele deverá recriá-lo. (Nota: pode não ser necessário reiniciar o serviço - apenas espere para ver se ele é recriado com o mesmo nome de arquivo por um minuto).

Pode levar algumas permissões e talvez seja necessário apropriar-se do arquivo e, em seguida, aplicar permissões. Nota: A propriedade não implica permissões. Você deve adicionar permissões depois de assumir a propriedade.

Como eu disse, não tenho acesso físico ao servidor - se você fizer isso, o que precede deve ser suficiente.

Tive a sorte de poder me conectar remotamente por meio de outra máquina na mesma rede local e alterar o registro.

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

Defina as chaves existentes SecurityLayer e UserAuthentication para 0

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 enablecredsspsupport:i:0 em algum lugar. Isso desativa a expectativa de segurança.

Quando você executa o arquivo RDP, ele deve permitir que você SEJA UNSECURELY conectado e obtenha acesso ao seu servidor.

Assim que você se conectar, altere essas duas entradas de registro e vá em frente e exclua o arquivo f686... ...

    

Answer 2

Estas configurações corrigiram meu problema:

1. No Painel de Controle, clique em Ferramentas Administrativas e, em seguida, clique duas vezes em Diretiva de Segurança Local.

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

3.Na 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 habilitei e enviei o comando underlist.

4. Executar gpupdate / force

Outra opção que resolverá este problema:

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

    

Answer 3

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

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

Às vezes, o IIS Crypto mostrará que o TLS está habilitado, embora não esteja habilitado no Registro apenas em um FYI.

Sua próxima opção é ativar o FIPS na política de grupo local, o que força o TLS 1.0, 1.1 e 1.2 a ser ativado e usado. Ative o FIPS e tente o RDP em sua máquina. Ele funcionará dessa vez mesmo que o TLS esteja desativado no registro. Você não quer usar o FIPS permanentemente, embora isso seja apenas para solução de problemas, portanto, desative-o no servidor e vá para o registro.

Vá para HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL e, em Protocolos, adicione três novas chaves, intitule-as TLS 1.0 , TLS 1.1 e TLS 1.2 , em seguida, crie duas subchaves sob cada entrada TLS. Título Client e Server .

Dentro das chaves Client e Server , crie duas entradas DWORD de 32 bits, uma chamada DisabledByDefault com o Value definido como 0 e Enabled com o valor definido como 1.

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