Requisitos e enumeração de certificado

• Aplica-se a:

  ✅ Windows 11, ✅ Windows 10, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

Este tópico para os desenvolvedores de cartão profissionais de TI e inteligentes descreve como os certificados são gerenciados e usados para cartão entrada inteligente.

Quando um cartão inteligente é inserido, as etapas a seguir são executadas.

Observação

A menos que seja mencionado de outra forma, todas as operações são executadas silenciosamente (CRYPT_SILENT é passada para CryptAcquireContext).

1. O banco de dados do gerenciador de recursos do smart cartão pesquisa o CSP (provedor de serviços criptográficos) do cartão inteligente.

2. Um nome de contêiner qualificado é construído usando o nome do leitor de cartão inteligente e ele é passado para o CSP. O formato é \\.<Reader name>\

3. CryptAcquireContext é chamado para recuperar um contexto para o contêiner padrão. Se ocorrer uma falha, o cartão inteligente será inutilizável para cartão entrada inteligente.

4. O nome do contêiner é recuperado usando o parâmetro PP_CONTAINER com CryptGetProvParam.

5. Usando o contexto adquirido na Etapa 3, o CSP é consultado para o parâmetro PP_USER_CERTSTORE. Para obter mais informações, consulte Arquitetura de Cartão Inteligente. Se a operação for bem-sucedida, o nome de um repositório de certificados será retornado e o fluxo do programa pulará para a Etapa 8.

6. Se a operação na Etapa 5 falhar, o contexto de contêiner padrão da Etapa 3 será consultado para a chave AT_KEYEXCHANGE.

7. Em seguida, o certificado é consultado do contexto de chave usando KP_CERTIFICATE. O certificado é adicionado a um repositório de certificados na memória.

8. Para cada certificado no repositório de certificados da Etapa 5 ou etapa 7, as seguintes verificações são executadas:

   1. O certificado deve ser válido, com base no relógio do sistema de computador (não expirado ou válido com uma data futura)
   2. O certificado não deve estar na parte AT_SIGNATURE de um contêiner
   3. O certificado deve ter um UPN (nome de entidade de usuário) válido
   4. O certificado deve ter o uso da chave de assinatura digital
   5. O certificado deve ter o EKU de logon de cartão inteligente

   Qualquer certificado que atenda a esses requisitos é exibido ao usuário com o UPN do certificado (ou endereço de email ou assunto, dependendo da presença das extensões de certificado)

9. O processo então escolhe um certificado e o PIN é inserido

10. LogonUI.exe empacota as informações e as envia para Lsass.exe para processar a tentativa de entrada

11. Se tiver êxito, LogonUI.exe fechará. Isso faz com que o contexto adquirido na Etapa 3 seja lançado

Fluxo de entrada de cartão inteligente no Windows

A maioria dos problemas durante a autenticação ocorre devido a alterações de comportamento da sessão. Quando ocorrem alterações, a LSA (Autoridade de Segurança Local) não requisitará o contexto da sessão; ele depende, em vez disso, do Provedor de Serviços Criptográficos para lidar com a alteração da sessão.

Certificados de cliente que não contêm um UPN no subjectAltName campo (SAN) do certificado podem ser habilitados para entrada, o que dá suporte a uma variedade maior de certificados e dá suporte a vários certificados de entrada no mesmo cartão.

O suporte para vários certificados no mesmo cartão está habilitado por padrão. Novos tipos de certificado devem ser habilitados por meio de Política de Grupo.

Se você habilitar a política Permitir chaves de assinatura válidas para a política de provedor de credenciais do Logon, todos os certificados disponíveis na cartão inteligente com uma chave somente assinatura serão listados na tela de entrada. Isso permite que os usuários selecionem sua experiência de entrada. Se a política estiver desabilitada ou não estiver configurada, certificados inteligentes baseados em cartão chave de assinatura não serão listados na tela de entrada.

O diagrama a seguir ilustra como o logon cartão inteligente funciona nas versões com suporte do Windows.

Fluxo de entrada smart cartão

A seguir estão as etapas executadas durante uma entrada de cartão inteligente:

1. O Winlogon solicita as informações de credencial da interface do usuário de entrada

2. De forma assíncrona, o gerenciador de recursos cartão inteligente é iniciado e o provedor de credencial de cartão inteligente faz o seguinte:

   1. Obtém informações de credencial (uma lista de credenciais conhecidas ou, se não houver credenciais, as informações inteligentes cartão leitor detectadas pelo Windows)
   2. Obtém uma lista de leitores de cartão inteligentes (usando a API do WinSCard) e a lista de cartões inteligentes inseridos em cada um deles
   3. Enumera cada cartão para verificar se um certificado de entrada controlado por Política de Grupo está presente. Se o certificado estiver presente, o provedor de credencial smart cartão copia-o em um cache temporário e seguro no computador ou terminal

   Observação

   Entradas de cache smartcard são criadas para certificados com um nome de assunto ou com um identificador de chave de assunto. Se o certificado tiver um nome de assunto, ele será armazenado com um índice baseado no nome da entidade e no emissor do certificado. Se outro certificado com o mesmo nome e emissor de certificado for usado, ele substituirá a entrada armazenada em cache existente. Uma alteração nesse comportamento permite a condição quando o certificado não tem um nome de assunto, o cache é criado com um índice baseado no identificador de chave do assunto e no emissor do certificado. Se outro certificado tiver o mesmo identificador de chave de assunto e emissor de certificado, a entrada de cache será substituída. Quando os certificados não têm um nome de assunto nem um identificador de chave de assunto, uma entrada armazenada em cache não é criada.

   1. Notifica a interface do usuário de entrada de que ela tem novas credenciais

3. A interface do usuário de entrada solicita as novas credenciais do provedor de credenciais de cartão inteligente. Como resposta, o provedor de credencial smart cartão fornece cada certificado de entrada para a interface do usuário de entrada e os blocos de entrada correspondentes são exibidos. O usuário seleciona um bloco de certificado de entrada baseado em cartão inteligente e o Windows exibe uma caixa de diálogo PIN

4. O usuário insere o PIN e, em seguida, pressiona ENTER. O provedor de credencial de cartão inteligente criptografa o PIN

5. O provedor de credencial que reside no sistema LogonUI coleta o PIN. Como parte das credenciais de empacotamento no provedor de credencial cartão inteligente, os dados são empacotados em uma estrutura de KERB_CERTIFICATE_LOGON. O conteúdo main da estrutura de KERB_CERTIFICATE_LOGON são os dados pin de cartão inteligente, CSP (como nome do leitor e nome do contêiner), nome de usuário e nome de domínio. O nome de usuário será necessário se o domínio de entrada não estiver na mesma floresta porque permite que um certificado seja mapeado para várias contas de usuário

6. O provedor de credencial encapsula os dados (como o PIN criptografado, o nome do contêiner, o nome do leitor e cartão especificação de chave) e os envia de volta ao LogonUI

7. O Winlogon apresenta os dados do LogonUI para o LSA com as informações do usuário no LSALogonUser

8. A LSA chama o pacote de autenticação Kerberos (Kerberos SSP) para criar uma solicitação de serviço de autenticação Kerberos (KRB_AS_REQ), que contém um pré-automático (conforme especificado no RFC 4556: Criptografia de Chave Pública para Autenticação Inicial em Kerberos (PKINIT)).

   Se a autenticação for executada usando um certificado que usa uma assinatura digital, os dados de pré-autenticação consistem no certificado público do usuário e no certificado assinado digitalmente com a chave privada correspondente.
   Se a autenticação for executada usando um certificado que usa oncifamento de chave, os dados de pré-autenticação consistem no certificado público do usuário e no certificado criptografado com a chave privada correspondente.

9. Para assinar a solicitação digitalmente (de acordo com o RFC 4556), uma chamada é feita para o CSP correspondente para uma operação de chave privada. Como a chave privada nesse caso é armazenada em um cartão inteligente, o subsistema smart cartão é chamado e a operação necessária é concluída. O resultado é enviado de volta para o provedor de suporte de segurança kerberos (SSP).

10. O SSP kerberos envia uma solicitação de autenticação para um TGT (tGT) (por RFC 4556) para o serviço KDC (Key Distribution Center) que é executado em um controlador de domínio.

11. O KDC localiza o objeto da conta do usuário em Active Directory Domain Services (AD DS), conforme detalhado nos requisitos e mapeamentos do certificado do cliente e usa o certificado do usuário para verificar a assinatura.

12. O KDC valida o certificado do usuário (tempo, caminho e status de revogação) para garantir que o certificado seja de uma fonte confiável. O KDC usa CryptoAPI para criar um caminho de certificação do certificado do usuário para um certificado de autoridade de certificação raiz (AC) que reside no repositório raiz no controlador de domínio. O KDC então usa CryptoAPI para verificar a assinatura digital no autenticador assinado que foi incluído nos campos de dados de pré-autenticação. O controlador de domínio verifica a assinatura e usa a chave pública do certificado do usuário para provar que a solicitação se originou do proprietário da chave privada que corresponde à chave pública. O KDC também verifica se o emissor é confiável e aparece no repositório de certificados NTAUTH.

13. O serviço KDC recupera informações da conta de usuário do AD DS. O KDC constrói um TGT, que se baseia nas informações da conta de usuário que ele recupera do AD DS. Os campos de dados de autorização do TGT incluem o SID (identificador de segurança) do usuário, os SIDs para grupos de domínio universais e globais aos quais o usuário pertence e (em um ambiente multidomain) os SIDs para todos os grupos universais dos quais o usuário é membro.

14. O controlador de domínio retorna o TGT para o cliente como parte da resposta KRB_AS_REP.

    Observação

    O pacote KRB_AS_REP consiste em:

    • Certificado de atributo privilege (PAC)
    • SID do usuário
    • SIDs de todos os grupos dos quais o usuário é membro
    • Uma solicitação de TGS (serviço de concessão de tíquetes)
    • Dados de pré-autenticação

    O TGT é criptografado com a chave master do KDC e a chave da sessão é criptografada com uma chave temporária. Essa chave temporária é derivada com base no RFC 4556. Usando CryptoAPI, a chave temporária é descriptografada. Como parte do processo de descriptografia, se a chave privada estiver em um cartão inteligente, uma chamada será feita ao subsistema smart cartão usando o CSP especificado para extrair o certificado correspondente à chave pública do usuário. (As chamadas programáticas para o certificado incluem CryptAcquireContext, CryptSetProvParam com o PIN, CryptgetUserKey e CryptGetKeyParam.) Depois que a chave temporária é obtida, o Kerberos SSP descriptografa a chave da sessão.

15. O cliente valida a resposta do KDC (tempo, caminho e status de revogação). Primeiro, verifica a assinatura do KDC pela construção de um caminho de certificação do certificado do KDC para uma AC raiz confiável e, em seguida, usa a chave pública do KDC para verificar a assinatura de resposta.

16. Agora que um TGT foi obtido, o cliente obtém um tíquete de serviço, que é usado para entrar no computador local.

17. Com êxito, a LSA armazena os ingressos e retorna uma mensagem de sucesso ao LSALogonUser. Depois que essa mensagem de sucesso é emitida, o perfil de usuário do dispositivo é selecionado e definido, Política de Grupo atualização é instanciada e outras ações são executadas.

18. Depois que o perfil de usuário é carregado, o Serviço de Propagação de Certificação (CertPropSvc) detecta esse evento, lê os certificados do cartão inteligente (incluindo os certificados raiz) e, em seguida, os preenche no MYSTORE (repositório de certificados) do usuário.

19. A comunicação do CSP para o gerenciador de recursos do cartão inteligente acontece no Canal LRPC.

20. Na autenticação bem-sucedida, os certificados são propagados para o repositório do usuário de forma assíncrona pelo Serviço de Propagação de Certificados (CertPropSvc).

21. Quando o cartão é removido, os certificados no repositório de cache seguro temporário são removidos. Os Certificados não estão mais disponíveis para entrada, mas permanecem no repositório de certificados do usuário.

Observação

Um SID é criado para cada usuário ou grupo no momento em que uma conta de usuário ou uma conta de grupo é criada no banco de dados de contas de segurança local ou no AD DS. O SID nunca será alterado, mesmo que a conta de usuário ou grupo seja renomeada.

Para obter mais informações sobre o protocolo Kerberos, consulte Microsoft Kerberos.

Por padrão, o KDC verifica se o certificado do cliente contém o EKU de autenticação do cliente cartão inteligente szOID_KP_SMARTCARD_LOGON. No entanto, se habilitado, a configuração Permitir certificados sem atributo de certificado de uso de chave estendida Política de Grupo permitirá que o KDC não exija o EKU SC-LOGON. O EKU SC-LOGON não é necessário para mapeamentos de conta baseados na chave pública.

Certificado KDC

Os Serviços de Certificado do Active Directory fornecem três tipos de modelos de certificado:

• Controlador de domínio
• Autenticação do controlador de domínio
• Autenticação Kerberos

Dependendo da configuração do controlador de domínio, um desses tipos de certificados é enviado como parte do pacote AS_REP.

Requisitos e mapeamentos de certificado do cliente

Os requisitos de certificado são listados por versões do sistema operacional Windows. O mapeamento de certificado descreve como as informações do certificado são mapeadas para a conta de usuário.

Requisitos de certificado

Componente	Requisitos
Local do ponto de distribuição do CRL	Não necessário
Uso de chave	Assinatura digital
Restrições básicas	Não necessário
EKU (uso de chave estendida)	O identificador de objeto de entrada cartão inteligente não é necessário. Nota Se um EKU estiver presente, ele deverá conter o EKU de entrada cartão inteligente. Certificados sem EKU podem ser usados para entrada.
Nome alternativo do assunto	A ID de email não é necessária para entrada inteligente cartão.
Requerente	Não necessário
Troca de chaves (campo AT_KEYEXCHANGE)	Não é necessário para certificados de entrada cartão inteligentes se uma configuração de Política de Grupo estiver habilitada. (Por padrão, as configurações de Política de Grupo não estão habilitadas.)
CRL	Não necessário
UPN	Não necessário
Observações	Você pode permitir que qualquer certificado fique visível para o provedor de credencial de cartão inteligente.

Mapeamentos de certificado do cliente

O mapeamento de certificado é baseado no UPN contido no campo subjectAltName (SAN) do certificado. Também há suporte para certificados de cliente que não contêm informações no campo SAN.

O SSL/TLS pode mapear certificados que não têm SAN e o mapeamento é feito usando os atributos AltSecID em contas de cliente. O X509 AltSecID, que é usado pela autenticação do cliente SSL/TLS, é do formulário "X509: <Issuer Name><Subject Name. O <Issuer Name> e <Subject Name> são retirados do certificado do cliente, com '\r' e '\n' substituídos por ','.

Pontos de distribuição de lista de revogação de certificado

UPN no campo Nome Alternativo do Assunto

Campos Assunto e Emissor

Esse mapeamento de conta é compatível com o KDC, além de outros seis métodos de mapeamento. A figura a seguir demonstra um fluxo de lógica de mapeamento da conta de usuário que é usado pelo KDC.

Fluxo de alto nível de processamento de certificado para entrada

O objeto certificado é analisado para procurar conteúdo para executar o mapeamento da conta de usuário.

• Quando um nome de usuário é fornecido com o certificado, o nome de usuário é usado para localizar o objeto da conta. Essa operação é a mais rápida, pois ocorre a correspondência de cadeia de caracteres
• Quando apenas o objeto certificado é fornecido, várias operações são executadas para localizar o nome de usuário para mapear o nome de usuário para um objeto de conta
• Quando nenhuma informação de domínio está disponível para autenticação, o domínio local é usado por padrão. Se qualquer outro domínio for usado para pesquisa, uma dica de nome de domínio deverá ser fornecida para executar o mapeamento e a associação

O mapeamento com base em atributos genéricos não é possível porque não há uma API genérica para recuperar atributos de um certificado. Atualmente, o primeiro método que localiza uma conta interrompe a pesquisa com êxito. Mas ocorre um erro de configuração se dois métodos mapearem o mesmo certificado para contas de usuário diferentes quando o cliente não fornecer o nome do cliente por meio das dicas de mapeamento.

A figura a seguir ilustra o processo de mapeamento de contas de usuário para entrada no diretório exibindo várias entradas no certificado.

Lógica de processamento de certificado

NT_AUTH política é melhor descrita na seção parâmetro CERT_CHAIN_POLICY_NT_AUTH da função CertVerifyCertificateChainPolicy. Para obter mais informações, consulte CertVerifyCertificateChainPolicy.

Logon cartão inteligente para um único usuário com um certificado em várias contas

Um único certificado de usuário pode ser mapeado para várias contas. Por exemplo, um usuário pode ser capaz de entrar em uma conta de usuário e também entrar como administrador de domínio. O mapeamento é feito usando o AltSecID construído com base em atributos de contas de cliente. Para obter informações sobre como esse mapeamento é avaliado, consulte Requisitos e mapeamentos de certificado do cliente.

Observação

Como cada conta tem um nome de usuário diferente, recomendamos que você habilite a configuração Permitir dica de nome de usuário Política de Grupo (chave de registro X509HintsNeeded) para fornecer os campos opcionais que permitem que os usuários insiram seus nomes de usuário e informações de domínio para entrar.

Com base nas informações disponíveis no certificado, as condições de entrada são:

1. Se nenhum UPN estiver presente no certificado:
   1. A entrada pode ocorrer na floresta local ou em outra floresta se um único usuário com um certificado precisar entrar em contas diferentes
   2. Uma dica deve ser fornecida se o mapeamento não for exclusivo (por exemplo, se vários usuários forem mapeados para o mesmo certificado)
2. Se um UPN estiver presente no certificado:
   1. O certificado não pode ser mapeado para vários usuários na mesma floresta
   2. O certificado pode ser mapeado para vários usuários em florestas diferentes. Para que um usuário entre em outras florestas, uma dica X509 deve ser fornecida ao usuário

Logon cartão inteligente para vários usuários em uma única conta

Um grupo de usuários pode entrar em uma única conta (por exemplo, uma conta de administrador). Para essa conta, os certificados de usuário são mapeados para que estejam habilitados para entrada.

Vários certificados distintos podem ser mapeados para uma única conta. Para que isso funcione corretamente, o certificado não pode ter UPNs.

Por exemplo, se Certificate1 tiver CN=CNName1, Certificate2 tiver CN=User1 e Certificado3 tiver CN=User2, o AltSecID desses certificados poderá ser mapeado para uma única conta usando o mapeamento de nome Usuários e Computadores do Active Directory.

Entrada cartão inteligente em florestas

Para que o mapeamento de conta funcione entre florestas, especialmente nos casos em que não há informações suficientes disponíveis no certificado, o usuário pode inserir uma dica na forma de um nome de usuário, como domínio\usuário, ou um UPN totalmente qualificado, como user@contoso.com.

Observação

Para que o campo de dicas apareça durante a entrada de cartão inteligente, a configuração Permitir dica de nome de usuário Política de Grupo (chave de registro X509HintsNeeded) deve estar habilitada no cliente.

Suporte do OCSP para PKINIT

O OCSP (Protocolo de Status do Certificado Online), definido no RFC 2560, permite que os aplicativos obtenham informações oportunas sobre a revogação status de um certificado. Como as respostas OCSP são pequenas e bem vinculadas, os clientes restritos podem querer usar o OCSP para marcar a validade dos certificados para Kerberos no KDC, para evitar a transmissão de CRLs grandes e para salvar a largura de banda em redes restritas. Para obter informações sobre as chaves do registro CRL, consulte Política de Grupo de Cartão Inteligente e Configurações do Registro.

Os KDCs no Windows tentam obter respostas OCSP e usá-las quando disponíveis. Esse comportamento não pode ser desabilitado. CryptoAPI for OCSP armazena em cache respostas OCSP e o status das respostas. O KDC dá suporte apenas a respostas OCSP para o certificado do signatário.

Os computadores cliente Windows tentam solicitar as respostas OCSP e usá-las na resposta quando estiverem disponíveis. Esse comportamento não pode ser desabilitado.

Requisitos de certificado raiz do smart cartão para uso com entrada de domínio

Para que a entrada funcione em um domínio inteligente baseado em cartão, o certificado de cartão inteligente deve atender às seguintes condições:

• O certificado raiz KDC no cartão inteligente deve ter um ponto de distribuição HTTP CRL listado em seu certificado
• O certificado de entrada cartão inteligente deve ter o ponto de distribuição HTTP CRL listado em seu certificado
• O ponto de distribuição crl deve ter um CRL válido publicado e um CRL delta, se aplicável, mesmo que o ponto de distribuição CRL esteja vazio
• O certificado de cartão inteligente deve conter um dos seguintes:
  • Um campo de assunto que contém o nome de domínio DNS no nome diferenciado. Se isso não ocorrer, a resolução para um domínio apropriado falhará, portanto, os Serviços de Área de Trabalho Remota e a entrada de domínio com o cartão inteligente falharão
  • Um UPN em que o nome de domínio se resolve para o domínio real. Por exemplo, se o nome de domínio for Engineering.Corp.Contoso, o UPN será username@engineering.corp.contoso.com. Se qualquer parte do nome de domínio for omitida, o cliente Kerberos não poderá encontrar o domínio apropriado

Para permitir que cartão inteligente entre em um domínio nestas versões, faça o seguinte:

1. Habilitar pontos de distribuição DE CRL HTTP na AC
2. Reiniciar a AC
3. Reemissar o certificado KDC
4. Emitir ou reemitir o certificado de entrada cartão inteligente
5. Propagar o certificado raiz atualizado para o cartão inteligente que você deseja usar para a entrada de domínio

A solução alternativa é habilitar a configuração Permitir dica de nome de usuário Política de Grupo (chave de registro X509HintsNeeded), que permite que o usuário forneça uma dica na interface do usuário de credenciais para entrada de domínio.

Se o computador cliente não estiver ingressado no domínio ou se ele estiver ingressado em um domínio diferente, o computador cliente poderá resolve o domínio do servidor apenas olhando para o nome diferenciado no certificado, não o UPN. Para que esse cenário funcione, o certificado requer um assunto completo, incluindo DC=<DomainControllerName>, para resolução de nome de domínio.

Para implantar certificados raiz em um cartão inteligente para o domínio ingressado no momento, você pode usar o seguinte comando:

certutil.exe -scroots update

Para obter mais informações sobre essa opção para a ferramenta de linha de comando, consulte -SCRoots.