O cliente RDP não considera o cartão inteligente válido para autenticação

O cliente RDP não considera o cartão inteligente válido para autenticação

Eu tenho:

  • Uma máquina cliente Windows 7. Não sou administrador dessa máquina.
  • Um servidor Windows 2008R2, no qual desejo abrir uma sessão usando a Área de Trabalho Remota.
  • AGateway de área de trabalho remota, também executando o Windows 2008R2.
  • Um cartão inteligente.

O servidor está configurado para permitir logon com cartão inteligente. O gateway também requer autenticação de cartão inteligente. Todos os clientes e servidores conhecem e confiam em todos os certificados de CA relevantes, nenhum certificado expirou, todas as CRL são publicadas onde deveriam.

Crucialmente, o certificado no cartão inteligente tem umUso estendido de chaveextensão (EKU) que NÃO contém o OID de "logon do cartão inteligente". Porém, possui "autenticação de cliente". O servidor e o gateway foram configurados para aceitar o certificado: esta é uma configuração de política chamada "Permitir certificados sem atributo de certificado de uso de chave estendida", conforme descrito.

O problema

O cliente usa um arquivo .rdp no qual é especificado o nome do servidoreo nome do gateway. Como o gateway é um gateway, e não um servidor de área de trabalho remota real, ele não possui uma "tela de login" para mostrar. Em vez disso, a autenticação de cartão inteligente depende de uma GUI gerenciada pelo cliente ( mstsc.exe, o cliente RD padrão no Windows) para permitir que o usuário selecione seu cartão inteligente e insira seu código PIN. Esta é a aparência do pop-up:

Pop-up de autenticação de cartão inteligente desejado

(Desculpe pelo pop-up em francês; não tenho um Windows 7 em inglês disponível.)

Infelizmente, esse pop-up não aparece assim. Em vez disso, recebo isto:

Pop-up real de autenticação de cartão inteligente

Análise

Conforme descritoaqui, o aplicativo cliente (mstsc.exe) permitirá que o sistema operacional (Windows 7) "enumere" os cartões inteligentes. O sistema operacional procurará cartões inteligentes contendo certificados que atendam a alguns critérios, em particular que qualquer extensão EKU encontrada em qualquer certificado contenha o OID de "logon do cartão inteligente". Isso é feito antes de realmente tentar se comunicar com o gateway, sem falar no servidor de destino final. O gateway e o servidor ficariam perfeitamente satisfeitos com meu certificado; eles foram configurados dessa forma. No entanto, o sistema operacional clienteimpõeas mesmas regras, de acordo com sua própria configuração. No meu caso, o Windows 7 se recusa a permitir que eu use meu cartão inteligente porque sua política local o rejeitaria para abrir uma sessão local (mesmo que eu não esteja tentando abrir uma sessão local).

Isso costumava funcionar com um cliente Windows XP, porque o "pop-up de seleção de cartão inteligente" do Windows XP não impõe essas verificações (o Windows XP verifica o EKU de uma forma ainda mais restritiva, porque não tolera a falta de extensão EKU, mas aplica essas verificações somente quando realmente tenta abrir uma sessão local, não ao selecionar um certificado para uma sessão remota).

A solução que não consigo usar

A solução "normal" é configurar o cliente local (Windows 7) com o mesmo "Permitir certificados sem atributo de certificado de uso de chave estendida" do servidor. Dessa forma, o pop-up de seleção do cartão inteligente agora aceita mostrar o cartão inteligente e está tudo bem. Eu testei em outro sistema. No entanto, não posso fazer isso nos meus sistemas de destino, porque a alteração da política local requer direitos de administrador, que não possuo. Da mesma forma, para clientes que fazem parte de um domínio, a configuração pode ser enviada de um GPO no servidor AD, que é novamente barrado para mim por falta de privilégios apropriados.

Pode-se dizer também que esta configuração de política na verdade permite o login na máquina cliente com um certificado que não possui o OID adequado em seu EKU, e isso pode ser considerado um efeito colateral indesejável. Estou tentando abrir uma sessão em umservidor remoto; Não deveria ter de alterar as condições de abertura de uma sessão nocliente local.

Versões mais antigas do mstsc.exe (do Windows XP) aparentemente poderiam se conectar ao servidor sem exigir qualquer autenticação do cliente; nesse caso, o servidor remoto exibiria sua tela de login (a "grande tela azul esverdeada") e cuidaria da própria enumeração do cartão inteligente. Como o servidor possui a política apropriada, isso funcionaria. No entanto, não posso usar tal solução por dois motivos:

  • O mstsc.exe do Windows 7 aparentemente insiste em fazer autenticação com seus próprios pop-ups.
  • Existe umPorta de entrada, que, ao contrário do servidor de destino final, não possui uma “tela de login” para mostrar. Ao usar um gateway que requer autenticação de cartão inteligente do cliente, a seleção do cartão inteligente do clientedeveser gerenciado pelo software cliente.

A questão

Então aqui está a minha pergunta: existe uma saída para esse problema? Idealmente, algum tipo de configuração em mstsc.exe (uma opção de linha de comando ou uma cláusula em um arquivo .rdp) que instruiria mstsc.exeNÃOusar o pop-up de seleção de cartão inteligente do sistema operacional, mas fazer a enumeração por conta própria,semtentando impor qualquer coisa sobre o EKU. Não encontrei nenhum vestígio de tal característica, mas a ausência de prova não é prova de ausência. Posso simplesmente ter perdido isso.

Responder1

Crie um arquivo .rdp para a conexão, defina enablecredsspsupport:i:0 dentro do arquivo .rdp e certifique-se de ter a opção de cartão inteligente para mapeamento de recursos locais ativada (o padrão é ativado, então esse já deve ser o caso, a menos que você alterou explicitamente a configuração.)

Consulte a seguinte entrada para obter mais detalhes: http://blogs.msdn.com/b/rds/archive/2007/01/22/vista-remote-desktop-connection-authentication-faq.aspx#_When_to_use

Eu não soubastantetenho certeza se isso funcionará para resolver seu problema por causa do gateway intermediário, mas, francamente, não consigo pensar em nenhuma outra solução possível para esse problema.

informação relacionada