Requisitos e enumeração de certificado

Este tópico para programadores de smart card e profissionais de TI descreve como os certificados são geridos e utilizados para o início de sessão de smart card.

Quando um smart card é inserido, são executados os seguintes passos.

1. A base de dados do gestor de recursos do smart card procura o fornecedor de serviços criptográficos (CSP) do smart card.

2. Um nome de contentor qualificado é construído com o nome do leitor de smart card e é transmitido para o CSP. O formato é \\.<Reader name>\

3. CryptAcquireContext é chamado para obter um contexto para o contentor predefinido. Se ocorrer uma falha, o smart card é inutilizável para o início de sessão do smart card.

4. O nome do contentor é obtido com o parâmetro PP_CONTAINER com CryptGetProvParam.

5. Com o contexto adquirido no Passo 3, o CSP é consultado para o parâmetro PP_USER_CERTSTORE. Para obter mais informações, veja Arquitetura de Smart Card. Se a operação for bem-sucedida, é devolvido o nome de um arquivo de certificados e o fluxo do programa passa para o Passo 8.

6. Se a operação no Passo 5 falhar, o contexto de contentor predefinido do Passo 3 é consultado para a chave de AT_KEYEXCHANGE.

7. Em seguida, o certificado é consultado a partir do contexto de chave com KP_CERTIFICATE. O certificado é adicionado a um arquivo de certificados dentro da memória.

8. Para cada certificado no arquivo de certificados do Passo 5 ou Passo 7, são efetuadas as seguintes verificações:

   1. O certificado tem de ser válido, com base no relógio do sistema informático (não expirado ou válido com uma data futura)
   2. O certificado não pode estar na parte AT_SIGNATURE de um contentor
   3. O certificado tem de ter um nome principal de utilizador (UPN) válido
   4. O certificado tem de ter a utilização da chave de assinatura digital
   5. O certificado tem de ter o EKU de início de sessão do smart card

   Qualquer certificado que cumpra estes requisitos é apresentado ao utilizador com o UPN do certificado (ou endereço de e-mail ou assunto, dependendo da presença das extensões de certificado)

9. Em seguida, o processo escolhe um certificado e o PIN é introduzido

10. LogonUI.exe empacota as informações e envia-as para Lsass.exe para processar a tentativa de início de sessão

11. Se for bem-sucedido, LogonUI.exe fecha. Isto faz com que o contexto adquirido no Passo 3 seja lançado

Fluxo de início de sessão de smart card 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 Autoridade de Segurança Local (LSA) não reenquira o contexto de sessão; Baseia-se, em vez disso, no Fornecedor de Serviços Criptográficos para processar a alteração da sessão.

Os certificados de cliente que não contêm um UPN no subjectAltName campo (SAN) do certificado podem ser ativados para início de sessão, que suporta uma maior variedade de certificados e suporta vários certificados de início de sessão no mesmo cartão.

O suporte para vários certificados no mesmo cartão está ativado por predefinição. Os novos tipos de certificado têm de ser ativados através da Política de Grupo.

Se ativar a política Permitir chaves de assinatura válidas para o fornecedor de credenciais de início de sessão, todos os certificados disponíveis no smart card com uma chave apenas de assinatura são listados no ecrã de início de sessão. Isto permite que os utilizadores selecionem a respetiva experiência de início de sessão. Se a política estiver desativada ou não estiver configurada, os certificados baseados em chave de assinatura do smart card não serão listados no ecrã de início de sessão.

O diagrama seguinte ilustra como funciona o início de sessão com smart card nas versões suportadas do Windows.

Fluxo de início de sessão de smart card

Seguem-se os passos efetuados durante o início de sessão do smart card:

1. O Winlogon pede as informações das credenciais da IU de início de sessão

2. De forma assíncrona, o gestor de recursos do smart card é iniciado e o fornecedor de credenciais do smart card faz o seguinte:

   1. Obtém informações de credenciais (uma lista de credenciais conhecidas ou, se não existirem credenciais, as informações do leitor de smart card detetadas pelo Windows)
   2. Obtém uma lista de leitores de smart card (utilizando a API WinSCard) e a lista de smart cards inseridos em cada um deles
   3. Enumera cada cartão para verificar se está presente um certificado de início de sessão controlado pela Política de Grupo. Se o certificado estiver presente, o fornecedor de credenciais do smart card copia-o para uma cache temporária e segura no computador ou terminal

   Observação

   As entradas de cache do Smartcard são criadas para certificados com um nome de requerente ou com um identificador de chave de assunto. Se o certificado tiver um nome de requerente, é armazenado com um índice baseado no nome do requerente e no emissor do certificado. Se for utilizado outro certificado com o mesmo nome de requerente e emissor de certificados, substituirá a entrada em cache existente. Uma alteração neste comportamento permite a condição quando o certificado não tem um nome de requerente, a cache é criada com um índice baseado no identificador da chave do requerente e no emissor do certificado. Se outro certificado tiver o mesmo identificador de chave de requerente e emissor de certificados, a entrada de cache é substituída. Quando os certificados não têm um nome de requerente nem identificador de chave de assunto, não é criada uma entrada em cache.

   1. Notifica a IU de início de sessão de que tem novas credenciais

3. A IU de início de sessão pede as novas credenciais ao fornecedor de credenciais do smart card. Como resposta, o fornecedor de credenciais de smart card fornece cada certificado de início de sessão à IU de início de sessão e os mosaicos de início de sessão correspondentes são apresentados. O utilizador seleciona um mosaico de certificado de início de sessão baseado em smart card e o Windows apresenta uma caixa de diálogo PIN

4. O utilizador introduz o PIN e, em seguida, prime ENTER. O fornecedor de credenciais do smart card encripta o PIN

5. O fornecedor de credenciais que reside no sistema LogonUI recolhe o PIN. Como parte das credenciais de empacotamento no fornecedor de credenciais do smart card, os dados são empacotados numa estrutura KERB_CERTIFICATE_LOGON. Os conteúdos principais da estrutura de KERB_CERTIFICATE_LOGON são o PIN do smart card, os dados CSP (como o nome do leitor e o nome do contentor), o nome de utilizador e o nome de domínio. O nome de utilizador é necessário se o domínio de início de sessão não estiver na mesma floresta porque permite que um certificado seja mapeado para várias contas de utilizador

6. O fornecedor de credenciais encapsula os dados (como o PIN encriptado, o nome do contentor, o nome do leitor e a especificação da chave do cartão) e envia-os de volta para LogonUI

7. O Winlogon apresenta os dados de LogonUI à LSA com as informações do utilizador no LSALogonUser

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

   Se a autenticação for efetuada com um certificado que utiliza uma assinatura digital, os dados de pré-autenticação consistem no certificado público do utilizador e no certificado assinado digitalmente com a chave privada correspondente.

   Se a autenticação for efetuada através de um certificado que utiliza a cifragem de chave, os dados de pré-autenticação consistem no certificado público do utilizador e no certificado encriptado com a chave privada correspondente.

9. Para assinar o pedido digitalmente (de acordo com RFC 4556), é feita uma chamada para o CSP correspondente para uma operação de chave privada. Uma vez que a chave privada neste caso está armazenada num smart card, o subsistema de smart card é chamado e a operação necessária é concluída. O resultado é enviado de volta para o fornecedor de suporte de segurança (SSP) Kerberos.

10. O Kerberos SSP envia um pedido de autenticação para uma permissão de concessão de permissão (TGT) (por RFC 4556) para o serviço do Centro de Distribuição de Chaves (KDC) que é executado num controlador de domínio.

11. O KDC localiza o objeto de conta do utilizador nos Serviços de Domínio do Active Directory (AD DS), conforme detalhado em Requisitos e mapeamentos de certificados de cliente, e utiliza o certificado do utilizador para verificar a assinatura.

12. O KDC valida o certificado do utilizador (hora, caminho e estado de revogação) para garantir que o certificado provém de uma origem fidedigna. O KDC utiliza a CryptoAPI para criar um caminho de certificação do certificado do utilizador para um certificado de autoridade de certificação (AC) de raiz que reside no arquivo raiz no controlador de domínio. Em seguida, o KDC utiliza 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 utiliza a chave pública do certificado do utilizador para provar que o pedido teve origem no proprietário da chave privada que corresponde à chave pública. O KDC também verifica se o emissor é fidedigno e aparece no arquivo de certificados NTAUTH.

13. O serviço KDC obtém as informações da conta de utilizador do AD DS. O KDC constrói um TGT, que se baseia nas informações da conta de utilizador que obtém do AD DS. Os campos de dados de autorização do TGT incluem o identificador de segurança (SID) do utilizador, os SIDs para grupos de domínios universais e globais aos quais o utilizador pertence e (num ambiente multidomain) os SIDs para quaisquer grupos universais dos quais o utilizador seja membro.

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

    Observação

    O pacote KRB_AS_REP consiste em:

    • Certificado de atributo de privilégio (PAC)
    • SID do utilizador
    • SIDs de quaisquer grupos dos quais o utilizador seja membro
    • Um pedido de serviço de concessão de permissão (TGS)
    • Dados de pré-autenticação

    O TGT é encriptado com a chave mestra do KDC e a chave de sessão é encriptada com uma chave temporária. Esta chave temporária é derivada com base no RFC 4556. Com a CryptoAPI, a chave temporária é desencriptada. Como parte do processo de desencriptação, se a chave privada estiver num smart card, é efetuada uma chamada para o subsistema de smart card com o CSP especificado para extrair o certificado correspondente à chave pública do utilizador. (As chamadas programáticas para o certificado incluem CryptAcquireContext, CryptSetProvParam com o PIN, CryptgetUserKey e CryptGetKeyParam.) Após a obtenção da chave temporária, o SSP kerberos desencripta a chave de sessão.

15. O cliente valida a resposta do KDC (estado de hora, caminho e revogação). Primeiro, verifica a assinatura do KDC através da construção de um caminho de certificação do certificado do KDC para uma AC de raiz fidedigna e, em seguida, utiliza a chave pública do KDC para verificar a assinatura de resposta.

16. Agora que foi obtido um TGT, o cliente obtém uma permissão de serviço, que é utilizada para iniciar sessão no computador local.

17. Com êxito, a LSA armazena os bilhetes e devolve uma mensagem de sucesso ao LSALogonUser. Após a emissão desta mensagem de êxito, o perfil de utilizador do dispositivo é selecionado e definido, a atualização da Política de Grupo é instanciada e outras ações são executadas.

18. Após o carregamento do perfil de utilizador, o Serviço de Propagação de Certificação (CertPropSvc) deteta este evento, lê os certificados do smart card (incluindo os certificados de raiz) e, em seguida, preenche-os no arquivo de certificados do utilizador (MYSTORE)

19. A comunicação do CSP para o gestor de recursos de smart card ocorre no Canal LRPC.

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

21. Quando o cartão é removido, os certificados no arquivo de cache segura temporário são removidos. Os Certificados já não estão disponíveis para início de sessão, mas permanecem no arquivo de certificados do utilizador.

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

Por predefinição, o KDC verifica se o certificado do cliente contém o EKU de autenticação de cliente de smart card szOID_KP_SMARTCARD_LOGON. No entanto, se estiver ativada, a definição Permitir certificados sem certificados de utilização de chaves expandidas de certificado de utilização de chaves permite 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 Certificados 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

Consoante a configuração do controlador de domínio, um destes tipos de certificados é enviado como parte do pacote AS_REP.

Requisitos e mapeamentos de certificados de cliente

Os requisitos de certificado são listados por versões do sistema operativo Windows. O mapeamento de certificados descreve como as informações do certificado são mapeadas para a conta de utilizador.

Requisitos de certificado

Mapeamentos de certificados de cliente

O mapeamento de certificados baseia-se no UPN que está contido no campo subjectAltName (SAN) do certificado. Os certificados de cliente que não contêm informações no campo SAN também são suportados.

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

Pontos de distribuição da lista de revogação de certificados

UPN no campo Nome Alternativo do Requerente

Campos Assunto e Emissor

Este mapeamento de conta é suportado pelo KDC, além de outros seis métodos de mapeamento. A figura seguinte demonstra um fluxo de lógica de mapeamento de conta de utilizador que é utilizado pelo KDC.

Fluxo de alto nível do processamento de certificados para início de sessão

O objeto de certificado é analisado para procurar conteúdo para efetuar o mapeamento da conta de utilizador.

• Quando um nome de utilizador é fornecido com o certificado, o nome de utilizador é utilizado para localizar o objeto de conta. Esta operação é a mais rápida, porque ocorre a correspondência de cadeias
• Quando apenas o objeto de certificado é fornecido, são realizadas várias operações para localizar o nome de utilizador para mapear o nome de utilizador para um objeto de conta
• Quando não existem informações de domínio disponíveis para autenticação, o domínio local é utilizado por predefinição. Se qualquer outro domínio for utilizado para pesquisa, deve ser fornecida uma sugestão de nome de domínio para efetuar o mapeamento e o enlace

O mapeamento com base em atributos genéricos não é possível porque não existe nenhuma API genérica para obter atributos de um certificado. Atualmente, o primeiro método que localiza uma conta interrompe com êxito a pesquisa. No entanto, ocorre um erro de configuração se dois métodos mapearem o mesmo certificado para contas de utilizador diferentes quando o cliente não fornecer o nome do cliente através das sugestões de mapeamento.

A figura seguinte ilustra o processo de mapeamento de contas de utilizador para início de sessão no diretório ao ver várias entradas no certificado.

Lógica de processamento de certificados

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

Início de sessão de smart card para um único utilizador com um certificado em várias contas

Um único certificado de utilizador pode ser mapeado para várias contas. Por exemplo, um utilizador poderá conseguir iniciar sessão numa conta de utilizador e também iniciar sessão como administrador de domínio. O mapeamento é feito com o AltSecID construído com base em atributos de contas de cliente. Para obter informações sobre como este mapeamento é avaliado, veja Requisitos e mapeamentos de certificados de cliente.

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

1. Se não existir nenhum UPN no certificado:
   1. O início de sessão pode ocorrer na floresta local ou noutra floresta se um único utilizador com um certificado precisar de iniciar sessão em contas diferentes
   2. Tem de ser fornecida uma sugestão se o mapeamento não for exclusivo (por exemplo, se vários utilizadores estiverem mapeados para o mesmo certificado)
2. Se estiver presente um UPN no certificado:
   1. O certificado não pode ser mapeado para vários utilizadores na mesma floresta
   2. O certificado pode ser mapeado para vários utilizadores em florestas diferentes. Para um utilizador iniciar sessão noutras florestas, tem de ser fornecida uma sugestão X509 ao utilizador

Início de sessão de smart card para vários utilizadores numa única conta

Um grupo de utilizadores pode iniciar sessão numa única conta (por exemplo, uma conta de administrador). Para essa conta, os certificados de utilizador são mapeados para que estejam ativados para início de sessão.

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

Por exemplo, se Certificate1 tiver CN=CNName1, Certificate2 tiver CN=User1 e Certificate3 tiver CN=User2, o AltSecID destes certificados pode ser mapeado para uma única conta através do mapeamento de nomes utilizadores e computadores do Active Directory.

Início de sessão com smart card entre florestas

Para que o mapeamento de contas funcione entre florestas, especialmente nos casos em que não existem informações suficientes disponíveis no certificado, o utilizador pode introduzir uma sugestão na forma de um nome de utilizador, como domínio\utilizador ou um UPN completamente qualificado, como user@contoso.com.

Suporte OCSP para PKINIT

O Protocolo OCSP (Online Certificate Status Protocol), definido no RFC 2560, permite que as aplicações obtenham informações oportunas sobre o estado de revogação de um certificado. Uma vez que as respostas OCSP são pequenas e bem vinculadas, os clientes restritos podem querer utilizar o OCSP para verificar a validade dos certificados para Kerberos no KDC, para evitar a transmissão de CRLs grandes e para guardar a largura de banda em redes restritas. Para obter informações sobre chaves de registo CRL, veja Política de Grupo de Smart Card e Definições de Registo.

Os KDCs no Windows tentam obter respostas OCSP e utilizá-las quando disponíveis. Este comportamento não pode ser desativado. A CryptoAPI para OCSP coloca em cache as respostas OCSP e o estado das respostas. O KDC suporta apenas respostas OCSP para o certificado de signatário.

Os computadores cliente Windows tentam pedir as respostas OCSP e utilizá-las na resposta quando estiverem disponíveis. Este comportamento não pode ser desativado.

Requisitos de certificado de raiz de smart card para utilização com o início de sessão no domínio

Para que o início de sessão funcione num domínio baseado em smart card, o certificado de smart card tem de cumprir as seguintes condições:

• O certificado de raiz KDC no smart card tem de ter um ponto de distribuição CRL HTTP listado no respetivo certificado
• O certificado de início de sessão do smart card tem de ter o ponto de distribuição CRL HTTP listado no respetivo certificado
• O ponto de distribuição crl tem de ter uma CRL válida publicada e uma CRL delta, se aplicável, mesmo que o ponto de distribuição crl esteja vazio
• O certificado de smart card tem de conter um dos seguintes:
  • Um campo de assunto que contém o nome de domínio DNS no nome único. Caso contrário, a resolução para um domínio adequado falha, pelo que os Serviços de Ambiente de Trabalho Remoto e o início de sessão do domínio com o smart card falham
  • Um UPN onde o nome de domínio é resolvido para o domínio real. Por exemplo, se o nome de domínio for Engineering.Corp.Contoso, o UPN é username@engineering.corp.contoso.com. Se qualquer parte do nome de domínio for omitida, o cliente Kerberos não conseguirá encontrar o domínio adequado

Para permitir o início de sessão de smart card num domínio nestas versões, faça o seguinte:

1. Ativar pontos de distribuição DE CRL HTTP na AC
2. Reiniciar a AC
3. Reeditar o certificado KDC
4. Emitir ou reeditar o certificado de início de sessão do smart card
5. Propagar o certificado de raiz atualizado para o smart card que pretende utilizar para o início de sessão do domínio

A solução é ativar a definição Permitir política de grupo de sugestão de nome de utilizador (X509HintsNeeded registry key), que permite ao utilizador fornecer uma sugestão na interface de utilizador de credenciais para o início de sessão de domínio.

Se o computador cliente não estiver associado ao domínio ou se estiver associado a um domínio diferente, o computador cliente só pode resolver o domínio do servidor ao observar o nome único no certificado e não o UPN. Para que este cenário funcione, o certificado requer um assunto completo, incluindo DC=<DomainControllerName>, para resolução de nomes de domínio.

Para implementar certificados de raiz num smart card para o domínio atualmente associado, pode utilizar o seguinte comando:

certutil.exe -scroots update

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