O RDP apresenta um certificado auto-assinado em vez de um certificado da Autoridade de Certificação

Question

Há alguns dias, presenciei um problema estranho no meu domínio:

• Durante a conexão RDP, vejo avisos de que o certificado não é confiável (e vejo um certificado autoassinado, não emitido pelo CA do domínio)

• Não consigo mais conectar por RDP a servidores com NLA (Network Layer Authentication) ativado.

Esse problema é onipresente - eu o experiencio em diferentes estações de trabalho e em diferentes servidores, incluindo o Windows Server 2012R2 | 2008R2, o Windows 7 e o Windows 10.

Sobre a infraestrutura da CA: uma CA raiz offline e uma CA de emissão no nível do domínio. O pkiview.msc diz que está tudo bem: tanto o Root quanto o Emissor possuem Certificados válidos, CDP's, IAI's e DeltaCRL's (somente emissor). Eu atualizei as CRLs raiz e as publiquei novamente no AD porque pensei que poderia ser o caso, mas sem sorte.

Modelo de certificado personalizado com cliente | Servidor | A autenticação RDP ainda existe e posso confirmar que os servidores em questão têm esses certificados na pasta Pessoal no Applet de Certificados MMC (e podem solicitar novos a partir deles), embora apenas o certificado auto-assinado seja presente na pasta RDP.

Usando o applet MMC Certificates, também vejo que os certificados Root e Issuer são confiáveis.

Então, eu realmente não sei o que fazer e como consertar, e porque ele está quebrado em primeiro lugar. Qualquer ajuda é apreciada.

PS. Além disso, há algum tempo, modifiquei o GPO do Domínio Padrão para impor os intervalos de IP da rede privada. Pode ser o motivo? De qualquer forma, eu dei as costas para o padrão e sem sorte também.

UPDATE Algumas fotos para esclarecer um pouco:

1) Aviso de segurança

2)...porqueosservidoresapresentamcertificadoauto-assinado

3)Noentanto,podemosverocertificadoCAapropriadoemarmazenamentopessoalnoservidoremquestão

4)NoarmazenamentodecertificadosdaÁreadeTrabalhoRemota,possoverapenasoCertificadoAuto-assinado.Eucopieioprópriolátambém,masnenhumefeito.EseeuexcluiroSelf-SignedCertdelá,nãoconseguireimeconectaraoservidorpormeiodoRDP.

5)TambémvocêpodeverqueminhasCAslocaissãoconfiáveispeloservidor:

6)EesseéoerroquereceboquandotentoRDPparaservidorhabilitadoparaNLA.Portanto,ocliente,poralgummotivo,nãopodeounãoiráusaroCredSSPdebomgrado.Funcionouumasemanaantes,entãoachoqueestáconectadoaoproblemadocert.

7)Finalmente,algumastelasdaCAdeemissão.Pareceestartudobem.

    

Answer 1

Às vezes, a ligação de certificados soltos do RDS para certificados estáticos (que não são atribuídos por meio do GPO). Você pode precisar executar o seguinte comando:

$path = (Get-WmiObject "Win32_TSGeneralSetting" -ComputerName "<RDS Server Name>" -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'").__path
Set-WmiInstance -Path $path -argument @{SSLCertificateSHA1Hash="<Thumbprint>"}

Substitua <RDS Server Name> pelo nome real do servidor (se executado remotamente) e <Thumbprint> pela impressão digital do certificado real. A impressão digital deve ser especificada em hexa sem espaços, por ex. F02B346CDC02165543936A37B50F2ED9D5285F62 .

Para máquinas internas (que são parte da floresta do AD e acessadas por meio de nomes internos), é recomendável usar certificados RDS atribuídos pelo GPO: Configurando certificados de área de trabalho remota

    

Answer 2

OK, eu resolvi isso. Michal Sokolowski estava certo quando apontou para a atualização do CredSSP de maio de 2018. Aparentemente, tudo que vi foi por causa disso. Assim que modifiquei o GPO local na estação de trabalho do cliente, tudo correu bem.

Então, a solução é:

1) execute gpedit.msc no cliente

2) abra a Configuração do Computador - > Modelos Administrativos - > Sistema - > Delegação de credenciais

3) habilite o Oracle Remediation de Criptografia e defina-o como Vulnerável

4) execute gpupdate / force

E tudo volta ao normal.