Erro do cliente RDP - Ocorreu um erro de autenticação (0x609)

Question

Eu tenho um computador chamado ws24 (192.168.1.168) e outro chamado srvPPassTest2.

Eu escrevi um programa rodando em ws24 que é um "proxy RDP". Ele aceita conexões de clientes RDP na porta 7070 (configurável) e as encaminha para srvPPassTest2. Eu faço o seguinte para configurar os computadores para usar o proxy:

• Eu crio um certificado para o Proxy com o seguinte comando:
  ./makecert -n "CN=ws24.pleasant.local" -pe -ss Root -sr localMachine -sky exchange -m 120 -r -a sha1 -eku 1.3.6.1.5.5.7.3.1
  • Em seguida, eu o exporto com chave privada para criar um .pfx que o proxy usará.
  • Eu também o exporto sem a chave privada e importo para os Certificados do srvPPassTest2 (Computador Local) - pasta Autoridades de Certificação Raiz Confiáveis / Certificado.
• eu corro em Enable-WSManCredSSP -role client -DelegateComputer srvPPassTest2 Enable-WSManCredSSP -role client -DelegateComputer ws24 Enable-WSManCredSSP -role client -DelegateComputer 192.168.1.168
  em ws24. Tenho certeza de que nem todos são necessários, mas ainda não estão funcionando, então estou tentando de tudo.
• No ws24, faço as seguintes alterações no registro:
  • Pacotes de segurança HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Lsa \ - adicione tspkg
  • HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders - adicione o arquivo credssp.dll
• Eu corro Enable-WSManCredSSP -role Server no srvPPassTest2.

Se você receber algum erro nas chamadas WSManCredSSP, tente chamar Enable-PSRemoting primeiro.

Veja o que acontece quando eu executo o proxy rdp e uso o cliente RDP para se conectar a ele:

• No ws24, eu uso o cliente RDP para conectar-me a 192.168.1.168:7070. O uso de um endereço IP em vez de um nome impede que o cliente responda que você não pode se conectar a si mesmo.
• O proxy recebe e modifica (se necessário) a mensagem ConnectionRequestPDU do Protocolo RDP para garantir que os sinalizadores SupportedProtocol estejam definidos como ProtocolHybrid & ProtocolSSL. Isso garantirá o uso do CredSSP. Isso é encaminhado para srvPPassTest2.
• O proxy mitm é o handshake de TLS.
• O proxy recebe a mensagem NTLMNegotiate dos clientes, obtém algumas informações dela e cria uma nova para encaminhar ao srvPPassTest2 de destino.
• Da mesma forma com o NTLMChallenge e NTLMAuthentication.
  • O cliente e servidor RDP continuam bem neste momento. Eles não retornam erros ou exibem um comportamento estranho.
• As máquinas trocam chaves públicas de certificado, criptografadas com a chave da troca do NTLM.
• O cliente envia um TSRequest com um TSCredential. O proxy recebe, verifica informações e constrói uma com credenciais diferentes para enviar para srvPPassTest2.
• Encaminhar mensagem do cliente, comprimento 462
• Encaminhar mensagem de srvppasstest2, tamanho 108
• Encaminhar mensagem do cliente, comprimento 12

Então eu recebo um pop-up de erro do cliente rdp:

An authentication error has occured (Code: 0x609)
Remote computer: 192.1.168.1.168

O único resultado relevante quando procuro o erro 0x609 é aqui e eu segui esses passos. Uma coisa importante a observar: eu tinha esse proxy trabalhando há 3 meses. Em seguida, srvPPassTest2 foi revertido para um estado anterior e agora o proxy não funciona. Eu não posso reverter o srvPPassTest2 para o estado quando estava funcionando, que vm não era meu e o snapshot não foi salvo por IT >: (

Onde alguém encontra informações sobre o código 0x609?

Quais outras configurações possíveis, em ws24 ou srvPPassTest2, estão faltando? Eu acho que o certificado provavelmente deveria estar em uma pasta adicional no srvPPassTest2, mas eu não sei qual.

Existe algo que eu possa fazer para solucionar problemas? As trocas NTLM e TSCredential estão funcionando perfeitamente.

    

Answer 1

O erro ocorreu nesta etapa:

• The proxy receives and modifies (if necessary) the ConnectionRequestPDU message of the RDP Protocol to ensure the SupportedProtocol flags are set to ProtocolHybrid & ProtocolSSL. This will ensure the use of CredSSP. That is forwarded to srvPPassTest2.

Como se constata, eu também tive que definir o sinalizador ProtocolHybridEx no ConnectionRequestPDU. Eu estou supondo que isso é porque as mensagens encaminhadas, aquelas após o TSCredential, se preocupam com esse sinalizador.

Sendo esse o caso, decidi apenas encaminhar as bandeiras usadas pelo cliente, em vez de construí-las sozinho. Se o sinalizador ProtocolHybrid não estiver definido, eu vou cometer um erro delicadamente, pois é necessário usar o NLA (Network Level Authentication).