Configure o NLA para não usar a verificação de credenciais do lado do cliente

Question

Situação: Usando uma estação de trabalho do Windows 10, que está no domínio OFFICE , inicio uma conexão RDP usando logon de cartão inteligente e certificados para um gateway RDS em um domínio externo REMOTE . O domínio estrangeiro aceita certificados do CA OFFICE-CA que emitiram certificados no cartão inteligente usado, que está no mesmo domínio que contém a estação de trabalho. A autenticação RDP resulta em um erro 0xc000006d / 0xc000006a (nome de usuário desconhecido). Os logs de eventos do servidor relatam que a autenticação foi tentada com credenciais explícitas que usaram o domínio de origem OFFICE em vez do domínio de destino REMOTE . Se eu testar o login localmente em um PC associado ao domínio REMOTE usando o mesmo cartão inteligente, o DC concederá acesso com o usuário [email protected] , que é igual a REMOTE\user . Assim, a autorização baseada em certificado é configurada corretamente.

Fui um pouco para frente e habilitei "Permitir dicas do usuário" na política de domínio OFFICE , permitindo que o cliente RDP do Windows 10 forneça o domínio \ nome de usuário esperado ao servidor RDS remoto, inicie a sessão RDP e forneça a sequência esperada REMOTE\user como dica do usuário para ajudar a autorizar a conexão. Desta vez, o RDP é bem-sucedido com a autorização com base nos logs do servidor, no entanto, o cliente RDP lança um erro "desconhecido do usuário" e fecha à força a conexão RDP do lado local. Analisando o problema, encontrei este artigo explicando o NLA que, entre outras coisas, contém o seguinte:

When you type your credentials into this dialog box, even if you don’t choose to save them, they go to CredSSP. This then passes the credentials to the RD Session Host server via a secure channel.

Portanto, a validação deve ter sucesso de qualquer forma, sugestão do usuário ou não. Aparentemente, o cliente% 10 RDP do Windowsmstsc.exe tenta validar as credenciais (o certificado) no lado local primeiro, determina o domínio \ nome de usuário e envia THAT para o lado remoto, que obviamente tem domínio \ nome_do_usuário diferente e não autoriza a conexão. Se eu ativar e fornecer a dica do usuário, a dica é aparentemente validada no lado local também e obviamente falha, enquanto o lado remoto valida corretamente as credenciais baseadas em certificado.

A pergunta é a seguinte:

1. Quando o comportamento inicial da NLA foi alterado?
2. Como posso controlar se a validação de credenciais do lado do cliente será usada antes de validá-las no lado remoto e desativá-la?
3. Preciso configurar algo extra no lado remoto para manter o NLA e permitir conexão RDP de um cliente RDP localizado em qualquer lugar que forneceu um certificado de cartão inteligente como credenciais, desde que o certificado seja válido?