Partilhar via


Como configurar a autenticação baseada em certificado do Microsoft Entra

A autenticação baseada em certificado (CBA) do Microsoft Entra permite que as organizações configurem seus locatários do Microsoft Entra para permitir ou exigir que os usuários se autentiquem com certificados X.509 criados pela PKI (Enterprise Public Key Infrastructure) para entrada em aplicativos e navegadores. Esse recurso permite que as organizações adotem autenticação moderna sem senha resistente a phishing usando um certificado x.509.

Durante o início de sessão, os utilizadores também veem uma opção para se autenticarem com um certificado em vez de introduzirem uma palavra-passe. Se vários certificados correspondentes estiverem presentes no dispositivo, o usuário pode escolher qual usar. O certificado é validado em relação à conta de usuário e, se for bem-sucedido, eles entrarão.

Siga estas instruções para configurar e usar o Microsoft Entra CBA para locatários nos planos Office 365 Enterprise e US Government. Você já deve ter uma PKI (infraestrutura de chave pública) configurada.

Pré-requisitos

Certifique-se de que os pré-requisitos seguintes estão em vigor:

  • Configure pelo menos uma autoridade de certificação (CA) e quaisquer CAs intermediárias no Microsoft Entra ID.
  • O usuário deve ter acesso a um certificado de usuário (emitido a partir de uma infraestrutura de chave pública confiável configurada no locatário) destinado à autenticação do cliente para autenticação no Microsoft Entra ID.
  • Cada autoridade de certificação deve ter uma lista de revogação de certificados (CRL) que possa ser referenciada a partir de URLs voltadas para a Internet. Se a autoridade de certificação confiável não tiver uma CRL configurada, a ID do Microsoft Entra não executará nenhuma verificação de CRL, a revogação de certificados de usuário não funcionará e a autenticação não será bloqueada.

Importante

Certifique-se de que a PKI é segura e não pode ser facilmente comprometida. No caso de um comprometimento, o invasor pode criar e assinar certificados de cliente e comprometer qualquer usuário no locatário, tanto os usuários que são sincronizados de usuários locais quanto somente na nuvem. No entanto, uma forte estratégia de proteção de chaves, juntamente com outros controles físicos e lógicos, como cartões de ativação HSM ou tokens para o armazenamento seguro de artefatos, pode fornecer defesa em profundidade para evitar que invasores externos ou ameaças internas comprometam a integridade da PKI. Para obter mais informações, consulte Protegendo PKI.

Importante

Visite as recomendações da Microsoft para obter práticas recomendadas para o Microsoft Cryptographic envolvendo escolha de algoritmo, comprimento de chave e proteção de dados. Por favor, certifique-se de usar um dos algoritmos recomendados, comprimento de chave e curvas aprovadas pelo NIST.

Importante

Como parte das melhorias de segurança contínuas, os pontos de extremidade Azure/M365 estão adicionando suporte para TLS1.3 e espera-se que esse processo leve alguns meses para cobrir os milhares de pontos de extremidade de serviço no Azure/M365. Isso inclui o ponto de extremidade do Microsoft Entra usado pela autenticação baseada em certificado (CBA) *.certauth.login.microsoftonline.com do Microsoft Entra e *.certauth.login.microsoftonline.uso . O TLS 1.3 é a versão mais recente do protocolo de segurança mais implantado da Internet, que criptografa dados para fornecer um canal de comunicação seguro entre dois terminais. O TLS 1.3 elimina algoritmos criptográficos obsoletos, aumenta a segurança em relação às versões mais antigas e visa criptografar o máximo possível do handshake. É altamente recomendável que os desenvolvedores comecem a testar o TLS 1.3 em seus aplicativos e serviços.

Nota

Ao avaliar uma PKI, é importante rever as políticas de emissão e aplicação de certificados. Como mencionado, adicionar autoridades de certificação (CAs) à configuração do Microsoft Entra permite que certificados emitidos por essas CAs autentiquem qualquer usuário no Microsoft Entra ID. Por esse motivo, é importante considerar como e quando as autoridades de certificação podem emitir certificados e como implementam identificadores reutilizáveis. Quando os administradores precisam garantir que apenas um certificado específico possa ser usado para autenticar um usuário, os administradores devem usar exclusivamente associações de alta afinidade para obter um nível mais alto de garantia de que apenas um certificado específico é capaz de autenticar o usuário. Para obter mais informações, consulte Ligações de alta afinidade.

Etapas para configurar e testar o Microsoft Entra CBA

Algumas etapas de configuração precisam ser feitas antes de habilitar o Microsoft Entra CBA. Primeiro, um administrador deve configurar as CAs confiáveis que emitem certificados de usuário. Como visto no diagrama a seguir, usamos o controle de acesso baseado em função para garantir que apenas administradores com privilégios mínimos sejam necessários para fazer alterações.

É necessário um Administrador Global para gerir esta funcionalidade.

Opcionalmente, você também pode configurar associações de autenticação para mapear certificados para autenticação de fator único ou multifator e configurar associações de nome de usuário para mapear o campo de certificado para um atributo do objeto de usuário. Os administradores de políticas de autenticação podem definir configurações relacionadas ao usuário. Quando todas as configurações estiverem concluídas, habilite o Microsoft Entra CBA no locatário.

Diagrama das etapas necessárias para habilitar a autenticação baseada em certificado do Microsoft Entra.

Etapa 1: Configurar as autoridades de certificação com armazenamento confiável baseado em PKI (Visualização)

O Entra tem um novo armazenamento confiável de autoridades de certificação (CA) baseado em PKI (infraestrutura de chave pública). O armazenamento confiável de CA baseado em PKI mantém as CAs dentro de um objeto de contêiner para cada PKI diferente. Os administradores podem gerenciar CAs em um contêiner com base em PKI mais facilmente do que uma lista simples de CAs.

O armazenamento confiável baseado em PKI tem limites mais altos para o número de autoridades de certificação e o tamanho de cada arquivo de autoridade de certificação. Um armazenamento confiável baseado em PKI suporta até 250 CAs e tamanho de 8 KB para cada objeto de CA. É altamente recomendável que você use o novo armazenamento confiável baseado em PKI para armazenar CAs, que é escalável e oferece suporte a novas funcionalidades, como dicas de emissores.

Nota

Se você usar o repositório confiável antigo para configurar CAs, recomendamos configurar um armazenamento confiável baseado em PKI.

Um administrador deve configurar as autoridades de certificação confiáveis que emitem certificados de usuário. Apenas os administradores menos privilegiados são necessários para fazer alterações. Um armazenamento confiável baseado em PKI tem funções RBAC, Administrador de Autenticação de Privilégios e Administrador de Autenticação.

O recurso Carregar PKI do armazenamento confiável baseado em PKI está disponível somente com a licença Microsoft Entra ID P1 ou P2. No entanto, com a licença gratuita também, os administradores podem carregar todas as CAs individualmente em vez do arquivo PKI e configurar o armazenamento confiável baseado em PKI.

Importante

Devido a um problema conhecido com a nova loja, recomenda-se não excluir todas as autoridades de certificação na loja antiga e ter pelo menos uma autoridade de certificação na loja antiga. Estamos trabalhando para corrigir o problema para remover a limitação.

Configurar autoridades de certificação usando o centro de administração do Microsoft Entra

Criar um objeto de contêiner PKI

  1. Crie um objeto de contêiner PKI.

  2. Entre no centro de administração do Microsoft Entra como um Administrador de Política de Autenticação.

  3. Navegue até Proteção>Mostrar mais>Central de Segurança (ou Pontuação Segura de Identidade) >Infraestrutura de chave pública (Visualização).

  4. Clique em + Criar PKI.

  5. Introduza o Nome a Apresentar.

  6. Clique em Criar.

    Diagrama das etapas necessárias para criar uma PKI.

  7. Selecione Colunas para adicionar ou excluir colunas.

  8. Selecione Atualizar para atualizar a lista de PKIs.

Excluir um objeto de contêiner PKI

  1. Para excluir uma PKI, selecione a PKI e selecione Excluir. Se a PKI tiver CAs, digite o nome da PKI para confirmar a exclusão de todas as CAs dentro dela e selecione Excluir.

    Diagrama das etapas necessárias para excluir uma PKI.

Carregar CAs individuais no objeto de contêiner PKI

  1. Para carregar uma autoridade de certificação no contêiner PKI:
    1. Clique em + Adicionar autoridade de certificação.

    2. Selecione o arquivo CA.

    3. Selecione Sim se a autoridade de certificação for um certificado raiz, caso contrário, selecione Não.

    4. Para URL da Lista de Revogação de Certificados, defina a URL voltada para a Internet para a CRL base da autoridade de certificação que contém todos os certificados revogados. Se o URL não estiver definido, a autenticação com certificados revogados não falhará.

    5. Para URL da Lista de Revogação de Certificados Delta, defina a URL voltada para a Internet para a CRL que contém todos os certificados revogados desde que a última CRL base foi publicada.

    6. O sinalizador Dicas do emissor está habilitado por padrão. Desative as dicas do emissor se a autoridade de certificação não deve ser incluída nas dicas do emissor.

    7. Selecione Guardar.

    8. Para excluir um certificado de autoridade de certificação, selecione o certificado e selecione Excluir.

      Diagrama de como excluir um certificado de autoridade de certificação.

    9. Selecione Colunas para adicionar ou excluir colunas.

    10. Selecione Atualizar para atualizar a lista de autoridades de certificação.

Carregue todas as autoridades de certificação com PKI de upload no objeto de contêiner PKI

  1. Para carregar todas as autoridades de certificação de uma só vez no contêiner PKI:

    1. Crie um objeto de contêiner PKI ou abra um.
    2. Selecione Carregar PKI.
    3. Digite o URL http voltado para a Internet onde o arquivo .p7b está disponível.
    4. Insira a soma de verificação SHA256 do arquivo.
    5. Selecione o upload.
    6. Carregar PKI é um processo assíncrono. À medida que cada autoridade de certificação é carregada, ela fica disponível na PKI. A conclusão do carregamento PKI pode levar até 30 minutos.
    7. Selecione Atualizar para atualizar as autoridades de certificação.

    Para gerar a soma de verificação SHA256 do arquivo PKI .p7b, execute este comando:

    Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256
    

Editar uma PKI

  1. Para editar PKI, selecione ... na linha PKI e selecione Editar.
  2. Insira um novo nome PKI e selecione Salvar.

Editar uma autoridade de certificação

  1. Para editar a autoridade de certificação, selecione ... na linha da autoridade de certificação e selecione Editar.
  2. Insira novos valores para o tipo de Autoridade de Certificação (raiz/intermediária), URL da CRL, URL da CRL Delta, sinalizador habilitado para Dicas do Emissor conforme necessário e selecione Salvar.

Restaurar uma PKI

  1. Selecione a guia PKIs excluídas .
  2. Selecione a PKI e selecione Restaurar PKI.

Restaurar uma autoridade de certificação

  1. Selecione a guia CAs excluídas .
  2. Selecione o arquivo CA e selecione Restaurar autoridade de certificação.

Noções básicas sobre o atributo isIssuerHintEnabled na autoridade de certificação

As dicas do emissor enviam de volta uma Indicação de CA Confiável como parte do handshake TLS (Transport Layer Security). A lista de autoridades de certificação confiáveis é definida como o assunto das autoridades de certificação carregadas pelo locatário no repositório confiável do Entra. Para obter mais informações sobre dicas de emissor, consulte Noções básicas sobre dicas de emissor.

Por padrão, os nomes de assunto de todas as autoridades de certificação no armazenamento confiável do Microsoft Entra são enviados como dicas. Se você quiser enviar uma dica apenas com CAs específicas, defina o atributo de dica do emissor isIssuerHintEnabled como true.

Há um limite de caracteres de 16 KB para as dicas do emissor (nome do assunto da autoridade de certificação) que o servidor pode enviar de volta para o cliente TLS. Como prática boa, defina o atributo isIssuerHintEnabled como true somente para as autoridades de certificação que emitem certificados de usuário.

Se várias autoridades de certificação intermediárias do mesmo certificado raiz emitirem os certificados de usuário final, todos os certificados aparecerão no seletor de certificados. Mas se você definir isIssuerHintEnabled como true para CAs específicas, somente os certificados de usuário adequados aparecerão no seletor de certificados. Para habilitar isIssuerHintEnabled, edite a autoridade de certificação e atualize o valor para true.

Configurar autoridades de certificação usando as APIs do Microsoft Graph

As APIs do Microsoft Graph podem ser usadas para configurar autoridades de certificação. Os exemplos a seguir mostram como usar o Microsoft Graph para executar operações de criação, leitura, atualização ou exclusão (CRUD) para uma PKI ou CA.

Criar um objeto de contêiner PKI

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/
Content-Type: application/json
{
   "displayName": "ContosoPKI"
}

Obter todos os objetos PKI

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations
ConsistencyLevel: eventual

Obter objeto PKI por PKI-id

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/{PKI-id}/
ConsistencyLevel: eventual

Carregar autoridades de certificação com um arquivo .p7b

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/{PKI-id}/certificateAuthorities/{CA-id}
Content-Type: application/json
{
    	"uploadUrl":"https://CBA/demo/CBARootPKI.p7b,
    	"sha256FileHash": "AAAAAAD7F909EC2688567DE4B4B0C404443140D128FE14C577C5E0873F68C0FE861E6F"
}

Obter todas as autoridades de certificação em uma PKI

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/{PKI-id}/certificateAuthorities
ConsistencyLevel: eventual

Obter uma autoridade de certificação específica dentro de uma PKI por CA-id

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/{PKI-id}/certificateAuthorities/{CA-id}
ConsistencyLevel: eventual

Atualizar sinalizador de dicas específicas do emissor da autoridade de certificação

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/{PKI-id}/certificateAuthorities/{CA-id}
Content-Type: application/json
{
   "isIssuerHintEnabled": true
}

Configurar autoridades de certificação (CA) usando o PowerShell Para essa configuração, você pode usar o [Microsoft Graph PowerShell] (/powershell/microsoftgraph/installation).

  1. Inicie o PowerShell com privilégios de administrador.

  2. Instale e importe o SDK do Microsoft Graph PowerShell.

    Install-Module Microsoft.Graph -Scope AllUsers
    Import-Module Microsoft.Graph.Authentication
    Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
    
  3. Conecte-se ao locatário e aceite tudo.

       Connect-MGGraph -Scopes "Directory.ReadWrite.All", "User.ReadWrite.All" -TenantId <tenantId>
    

Registo de auditoria

Todas as operações CRUD em uma PKI ou CA dentro do armazenamento confiável são registradas nos logs de auditoria do Microsoft Entra.

Diagrama de logs de auditoria.

FAQs

Pergunta: Por que a PKI de upload falha?

Resposta: Verifique se o arquivo PKI é válido e pode ser acessado sem problemas. O tamanho máximo do arquivo PKI deve ser

Pergunta: O que é o contrato de nível de serviço (SLA) para carregamento de PKI?

Resposta: O carregamento PKI é uma operação assíncrona e pode levar até 30 minutos para ser concluído.

Pergunta: Como você gera a soma de verificação SHA256 para o arquivo PKI?

Resposta: Para gerar a soma de verificação SHA256 do arquivo PKI.p7b, execute este comando:

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

Etapa 2: Habilitar o CBA no locatário

Importante

Um usuário é considerado capaz para MFA quando o usuário está no escopo para autenticação baseada em certificado na política de métodos de autenticação. Este requisito de política significa que um usuário não pode usar a prova como parte de sua autenticação para registrar outros métodos disponíveis. Se os usuários não tiverem acesso a certificados, eles serão bloqueados e não poderão registrar outros métodos para MFA. Os administradores de políticas de autenticação precisam habilitar o CBA apenas para usuários que tenham certificados válidos. Não inclua Todos os usuários para CBA. Use apenas grupos de usuários com certificados válidos disponíveis. Para obter mais informações, consulte Autenticação multifator do Microsoft Entra.

Para habilitar o CBA no centro de administração do Microsoft Entra, conclua as seguintes etapas:

  1. Entre no centro de administração do Microsoft Entra como pelo menos um Administrador de Política de Autenticação.

  2. Navegue até Grupos>>, selecione Novo grupo e crie um grupo para usuários do CBA.

  3. Navegue até Métodos>Autenticação baseada em certificado.

  4. Em Ativar e Destino, selecione Ativar.

  5. Selecione Adicionar grupos para selecionar grupos específicos como o que você criou. Use grupos específicos em vez de Todos os usuários.

    Captura de tela de como ativar o CBA.

Depois que a autenticação baseada em certificado estiver habilitada no locatário, todos os usuários no locatário verão a opção para entrar com um certificado. Somente os usuários habilitados para CBA podem se autenticar usando o certificado X.509.

Nota

O administrador de rede deve permitir o acesso ao ponto de extremidade certo para o ambiente de nuvem do cliente, além do login.microsoftonline.com. Desative a inspeção TLS no ponto de extremidade certauth para garantir que a solicitação de certificado do cliente seja bem-sucedida como parte do handshake TLS.

Etapa 3: Configurar a política de vinculação de autenticação

A política de vinculação de autenticação ajuda a determinar a força da autenticação para um único fator ou multifator. O nível de proteção padrão para os certificados no locatário é a autenticação de fator único.

Um Administrador de Política de Autenticação pode alterar o valor padrão de fator único para multifator e configurar regras de política personalizadas. As regras de vinculação de autenticação mapeiam atributos de certificado, como Emissor ou ID de Objeto de Política (OID) ou Emissor e OID de Política, para um valor e selecionam o nível de proteção padrão para essa regra. Você pode criar várias regras.

Para modificar as configurações padrão do locatário no centro de administração do Microsoft Entra, conclua as seguintes etapas:

  1. Entre no centro de administração do Microsoft Entra como pelo menos um Administrador de Política de Autenticação.

  2. Navegue até Políticas de métodos>de autenticação de proteção>.

  3. Em Gerenciar, selecione Métodos>de autenticação Autenticação baseada em certificado.

    Captura de ecrã da política de Autenticação.

  4. Selecione Configurar para configurar a vinculação de autenticação e a vinculação de nome de usuário.

  5. O atributo de nível de proteção tem um valor padrão de autenticação de fator único. Selecione Autenticação multifator para alterar o valor padrão para MFA.

    Nota

    O valor do nível de proteção padrão estará em vigor se nenhuma regra personalizada for adicionada. Se forem adicionadas regras personalizadas, o nível de proteção definido no nível da regra será respeitado.

    Captura de tela de como alterar a política padrão para MFA.

  6. Você também pode configurar regras de vinculação de autenticação personalizadas para ajudar a determinar o nível de proteção para certificados de cliente. Ele pode ser configurado usando os campos Assunto do emissor ou OID de política no certificado.

    As regras de vinculação de autenticação mapeiam os atributos do certificado (emissor ou Policy OID) para um valor e selecionam o nível de proteção padrão para essa regra. Várias regras podem ser criadas.

    Para adicionar regras personalizadas, selecione Adicionar regra.

    Captura de ecrã de como adicionar uma regra.

    Para criar uma regra por emissor de certificado, selecione Emissor de certificado.

    1. Selecione um identificador de emissor de certificado na caixa de listagem.

    2. Selecione Autenticação multifator, Ligação de baixa afinidade e clique em Adicionar. Quando solicitado, clique em Reconheço para concluir a adição da regra.

      Captura de ecrã da política de autenticação multifator.

    Para criar uma regra por Policy OID, selecione Policy OID.

    1. Insira um valor para Policy OID.

    2. Selecione Autenticação multifator, Ligação de baixa afinidade e clique em Adicionar. Quando solicitado, clique em Reconheço para concluir a adição da regra.

      Captura de tela do mapeamento para Policy OID.

    Para criar uma regra por OID de emissor e política:

    1. Selecione Emissor de certificado e OID de política.

    2. Selecione um emissor e insira o OID da política.

    3. Em Força da autenticação, selecione Autenticação de fator único ou Autenticação multifator.

    4. Para Vinculação de afinidade, selecione Baixa.

      Captura de tela de como selecionar uma associação de baixa afinidade.

    5. Selecione Adicionar.

      Captura de tela de como adicionar uma associação de baixa afinidade.

    6. Autentique-se com um certificado que tenha a política OID de 3.4.5.6 e emitido por CN=CBATestRootProd. A autenticação deve passar e obter uma reivindicação multifator.

Importante

Há um problema conhecido em que um Administrador de Política de Autenticação de Locatário do Microsoft Entra configura uma regra de política de autenticação CBA usando o Emissor e o OID de Política. O problema afeta alguns cenários de registro de dispositivo, incluindo:

  • Inscrição no Windows Hello para Empresas
  • Registo da chave de segurança FIDO2
  • Login de telefone sem senha do Windows

O registro de dispositivos com os cenários de ingresso no local de trabalho, ID do Microsoft Entra e ingresso de dispositivo híbrido do Microsoft Entra não é afetado. As regras da política de autenticação CBA que usam o Emissor OU o OID da Política não são afetadas. Para atenuar, os administradores devem:

  • Edite as regras de política de autenticação baseada em certificado que usam as opções Emissor e OID de Política. Remova o requisito de OID de emissor ou de política e salve. -Ou-
  • Remova a regra de política de autenticação que usa o Emissor e o OID da Política. Crie regras que usem apenas o OID do Emissor ou da Política.

Estamos a trabalhar para corrigir o problema.

Para criar uma regra por Emissor e Número de Série:

  1. Adicione uma política de vinculação de autenticação. A política requer que qualquer certificado emitido por CN=CBATestRootProd com policyOID 1.2.3.4.6 precise apenas de ligação de alta afinidade. O emissor e o número de série são usados.

    A captura de tela do Emissor e do Número de Série adicionou o centro de administração do Microsoft Entra.

  2. Selecione o campo de certificado. Neste exemplo, vamos selecionar Emissor e Número de série.

    Captura de tela de como selecionar Emissor e Número de Série.

  3. O único atributo de usuário suportado é CertificateUserIds. Selecione Adicionar.

    Captura de ecrã de como adicionar o Emissor e o Número de Série.

  4. Selecione Guardar.

    O log de entrada mostra qual associação foi usada para entrar e os detalhes do certificado.

    Captura de ecrã do registo de início de sessão.

  5. Selecione Ok para salvar qualquer regra personalizada.

Importante

Insira o PolicyOID usando o formato de identificador de objeto. Por exemplo, se a política de certificado disser Todas as Políticas de Emissão, insira o OID como 2.5.29.32.0 quando adicionar a regra. A cadeia de caracteres Todas as Políticas de Emissão é inválida para o editor de regras e não entra em vigor.

Etapa 4: Configurar a política de vinculação de nome de usuário

A política de vinculação de nome de usuário ajuda a validar o certificado do usuário. Por padrão, mapeamos Nome Principal no certificado para UserPrincipalName no objeto de usuário para determinar o usuário.

Um administrador de política de autenticação pode substituir o padrão e criar um mapeamento personalizado. Para determinar como configurar a vinculação de nome de usuário, consulte Como funciona a vinculação de nome de usuário.

Para outros cenários que usam o atributo certificateUserIds, consulte IDs de usuário de certificado.

Importante

Se uma política de vinculação de nome de usuário usar atributos sincronizados, como o atributo certificateUserIds, onPremisesUserPrincipalName e userPrincipalName do objeto de usuário, lembre-se de que contas com privilégios administrativos no Ative Directory (como aquelas com direitos delegados em objetos de usuário ou direitos administrativos no Microsoft Entra Connect Server) podem fazer alterações que afetam esses atributos no Microsoft Entra ID.

  1. Crie a associação de nome de usuário selecionando um dos campos de certificado X.509 para vincular a um dos atributos de usuário. A ordem de vinculação do nome de usuário representa o nível de prioridade da vinculação. O primeiro tem a maior prioridade, e assim por diante.

    Captura de ecrã de uma política de associação de nome de utilizador.

    Se o campo de certificado X.509 especificado for encontrado no certificado, mas o Microsoft Entra ID não encontrar um objeto de usuário usando esse valor, a autenticação falhará. O Microsoft Entra ID tenta a próxima ligação na lista.

  2. Selecione Guardar para guardar as alterações.

A configuração final é semelhante a esta imagem:

Captura de tela da configuração final.

Etapa 5: Testar sua configuração

Esta seção aborda como testar seu certificado e regras de vinculação de autenticação personalizadas.

Teste o seu certificado

Como um primeiro teste de configuração, você deve tentar entrar no portal MyApps usando seu navegador no dispositivo.

  1. Introduza o seu Nome Principal de Utilizador (UPN).

    Captura de ecrã do Nome Principal do Utilizador.

  2. Selecione Seguinte.

    Captura de ecrã do início de sessão com certificado.

    Se tiver ativado outros métodos de autenticação, como o início de sessão por telefone ou FIDO2, os utilizadores poderão ver um ecrã de início de sessão diferente.

    Captura de ecrã do início de sessão alternativo.

  3. Selecione Entrar com um certificado.

  4. Escolha o certificado de usuário correto na interface do usuário do seletor de certificados do cliente e selecione OK.

    Captura de tela da interface do usuário do seletor de certificados.

  5. Os usuários devem estar conectados ao portal MyApps.

Se o seu início de sessão for bem-sucedido, sabe que:

  • O certificado de usuário é provisionado em seu dispositivo de teste.
  • O Microsoft Entra ID está configurado corretamente com CAs confiáveis.
  • A associação de nome de usuário está configurada corretamente e o usuário é encontrado e autenticado.

Testar regras de vinculação de autenticação personalizadas

Vamos percorrer um cenário em que validamos a autenticação forte. Criamos duas regras de política de autenticação, uma usando o sujeito do emissor para satisfazer a autenticação de fator único e outra usando a política OID para satisfazer a autenticação multifator.

  1. Crie uma regra de assunto do emissor com nível de proteção como autenticação de fator único e valor definido para o valor de assunto das autoridades de certificação. Por exemplo:

    CN = WoodgroveCA

  2. Crie uma regra OID de política, com nível de proteção como autenticação multifator e valor definido como um dos OIDs de política em seu certificado. Por exemplo, 1.2.3.4.

    Captura de ecrã da regra Policy OID.

  3. Crie uma política de Acesso Condicional para que o usuário exija autenticação multifator seguindo as etapas em Acesso Condicional - Exigir MFA.

  4. Navegue até o portal MyApps. Introduza o seu UPN e selecione Seguinte.

    Captura de ecrã do Nome Principal do Utilizador.

  5. Selecione Entrar com um certificado.

    Captura de ecrã do início de sessão com certificado.

    Se tiver ativado outros métodos de autenticação, como o início de sessão por telefone ou chaves de segurança, os utilizadores poderão ver um ecrã de início de sessão diferente.

    Captura de ecrã do início de sessão alternativo.

  6. Selecione o certificado do cliente e selecione Informações do certificado.

    Captura de tela do seletor de clientes.

  7. O certificado é exibido e você pode verificar os valores OID do emissor e da política. Captura de tela do emissor.

  8. Para ver os valores OID da política, selecione Detalhes.

    Captura de ecrã dos detalhes de autenticação.

  9. Selecione o certificado do cliente e selecione OK.

  10. O OID de política no certificado corresponde ao valor configurado de 1.2.3.4 e satisfaz a autenticação multifator. Da mesma forma, o emissor no certificado corresponde ao valor configurado de CN=WoodgroveCA e satisfaz a autenticação de fator único.

  11. Como a regra OID de política tem precedência sobre a regra do emissor, o certificado satisfaz a autenticação multifator.

  12. A política de Acesso Condicional para o usuário requer MFA e o certificado satisfaz multifator, para que o usuário possa entrar no aplicativo.

Testar a política de vinculação de nome de usuário

A política de vinculação de nome de usuário ajuda a validar o certificado do usuário. Há três associações que são suportadas para a política de vinculação de nome de usuário:

  • EmissorAndSerialNumber>CertificateUserIds
  • IssuerAndSubject>CertificateUserIds
  • Assunto>CertificateUserIds

Por padrão, o ID do Microsoft Entra mapeia Nome Principal no certificado para UserPrincipalName no objeto de usuário para determinar o usuário. Um administrador de política de autenticação pode substituir o padrão e criar um mapeamento personalizado, conforme explicado anteriormente.

Um administrador de política de autenticação precisa habilitar as novas associações. Para se preparar, eles devem certificar-se de que os valores corretos para as associações de nome de usuário correspondentes sejam atualizados no atributo CertificateUserIds do objeto de usuário:

Importante

O formato dos valores de Emitente, Assunto e Número de Série deve estar na ordem inversa do seu formato no certificado. Não adicione espaço no Emissor ou Assunto.

Mapeamento manual do emissor e do número de série

Aqui está um exemplo de mapeamento manual do Emissor e do Número de Série. O valor acrescentado do emitente é:

C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate

Captura de ecrã do valor do Emissor.

Para obter o valor correto para o número de série, execute o seguinte comando e armazene o valor mostrado em CertificateUserIds. A sintaxe do comando é:

Certutil –dump –v [~certificate path~] >> [~dumpFile path~] 

Por exemplo:

certutil -dump -v firstusercert.cer >> firstCertDump.txt

Aqui está um exemplo para o comando certutil:

certutil -dump -v C:\save\CBA\certs\CBATestRootProd\mfausercer.cer 

X509 Certificate: 
Version: 3 
Serial Number: 48efa06ba8127299499b069f133441b2 

   b2 41 34 13 9f 06 9b 49 99 72 12 a8 6b a0 ef 48 

O valor SerialNumber a ser adicionado em CertificateUserId é:

B24134139F069B49997212A86BA0EF48

CertificateUserId:

X509:<I>C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate<SR> b24134139f069b49997212a86ba0ef48 

Mapeamento manual de problemas e assuntos

Aqui está um exemplo de mapeamento manual de Problema e Assunto. O valor do emitente é:

Captura de tela do valor Emissor quando usado com várias associações.

O valor Subject é:

Captura de ecrã do valor Assunto.

CertificateUserId:

X509:<I>C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate<S> DC=com,DC=contoso,DC=corp,OU=UserAccounts,CN=FirstUserATCSession

Mapeamento manual do assunto

Aqui está um exemplo de mapeamento manual do assunto. O valor Subject é:

Captura de ecrã de outro valor de Assunto.

CertificateUserId:

X509:<S>DC=com,DC=contoso,DC=corp,OU=UserAccounts,CN=FirstUserATCSession

Ligação de afinidade de teste

  1. Entre no centro de administração do Microsoft Entra como pelo menos um Administrador de Política de Autenticação.

  2. Navegue até Políticas de métodos>de autenticação de proteção>.

  3. Em Gerenciar, selecione Métodos>de autenticação Autenticação baseada em certificado.

  4. Selecione Configurar.

  5. Defina a Vinculação de Afinidade Necessária no nível do locatário.

    Importante

    Tenha cuidado com a configuração de afinidade de todo o locatário. Você pode bloquear todo o locatário se alterar a Vinculação de Afinidade Necessária para o locatário e não tiver valores adequados no objeto de usuário. Da mesma forma, se você criar uma regra personalizada que se aplique a todos os usuários e exija uma associação de alta afinidade, os usuários no locatário poderão ser bloqueados.

    Captura de tela de como definir a associação de afinidade necessária.

  6. Para testar, selecione Ligação de afinidade necessária para ser baixa.

  7. Adicione uma ligação de alta afinidade como SKI. Selecione Adicionar regra em Vinculação de nome de usuário.

  8. Selecione SKI e selecione Adicionar.

    Captura de tela de como adicionar uma associação de afinidade.

    Quando terminar, a regra se parece com esta captura de tela:

    Captura de tela de uma associação de afinidade concluída.

  9. Atualize todos os objetos de usuário CertificateUserIds atributo para ter o valor correto de SKI do certificado de usuário. Para obter mais informações, consulte Padrões suportados para CertificateUserIDs.

  10. Crie uma regra personalizada para vinculação de autenticação.

  11. Selecione Adicionar.

    Captura de ecrã de uma ligação de autenticação personalizada.

    Quando terminar, a regra se parece com esta captura de tela:

    Captura de ecrã de uma regra personalizada.

  12. Atualize o usuário CertificateUserIds com o valor SKI correto do certificado com a política OID 9.8.7.5.

  13. Teste com um certificado com a política OID 9.8.7.5 e o usuário deve ser autenticado com a ligação SKI e obter MFA apenas com o certificado.

Habilitar o CBA usando a API do Microsoft Graph

Para habilitar o CBA e configurar associações de nome de usuário usando a API do Graph, conclua as etapas a seguir.

  1. Vá para Microsoft Graph Explorer.

  2. Selecione Entrar no Graph Explorer e entre no seu locatário.

  3. Siga as etapas para consentir com a permissão delegada Policy.ReadWrite.AuthenticationMethod.

  4. OBTER todos os métodos de autenticação:

    GET  https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy
    
  5. OBTENHA a configuração para o método de autenticação de certificado x509:

    GET https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy/authenticationMethodConfigurations/X509Certificate
    
  6. Por padrão, o método de autenticação de certificado x509 está desabilitado. Para permitir que os usuários entrem com um certificado, você deve habilitar o método de autenticação e configurar as políticas de vinculação de autenticação e nome de usuário por meio de uma operação de atualização. Para atualizar a política, execute uma solicitação PATCH.

    Corpo do pedido:

    PATCH https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate
    Content-Type: application/json
    
    {
        "@odata.type": "#microsoft.graph.x509CertificateAuthenticationMethodConfiguration",
        "id": "X509Certificate",
        "state": "enabled",
        "certificateUserBindings": [
            {
                "x509CertificateField": "PrincipalName",
                "userProperty": "onPremisesUserPrincipalName",
                "priority": 1
            },
            {
                "x509CertificateField": "RFC822Name",
                "userProperty": "userPrincipalName",
                "priority": 2
            }, 
            {
                "x509CertificateField": "PrincipalName",
                "userProperty": "certificateUserIds",
                "priority": 3
            }
        ],
        "authenticationModeConfiguration": {
            "x509CertificateAuthenticationDefaultMode": "x509CertificateSingleFactor",
            "rules": [
                {
                    "x509CertificateRuleType": "issuerSubject",
                    "identifier": "CN=WoodgroveCA ",
                    "x509CertificateAuthenticationMode": "x509CertificateMultiFactor"
                },
                {
                    "x509CertificateRuleType": "policyOID",
                    "identifier": "1.2.3.4",
                    "x509CertificateAuthenticationMode": "x509CertificateMultiFactor"
                }
            ]
        },
        "includeTargets": [
            {
                "targetType": "group",
                "id": "all_users",
                "isRegistrationRequired": false
            }
        ]
    }
    
  7. Você recebe um código de 204 No content resposta. Execute novamente a solicitação GET para garantir que as políticas sejam atualizadas corretamente.

  8. Teste a configuração entrando com um certificado que satisfaça a política.

Habilitar o CBA usando o Microsoft PowerShell

  1. Abra o PowerShell.
  2. Conecte-se ao Microsoft Graph:
    Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"
    
  3. Crie uma variável para definir o grupo para usuários do CBA:
    $group = Get-MgGroup -Filter "displayName eq 'CBATestGroup'"
    
  4. Defina o corpo da solicitação:
    $body = @{
    "@odata.type" = "#microsoft.graph.x509CertificateAuthenticationMethodConfiguration"
    "id" = "X509Certificate"
    "state" = "enabled"
    "certificateUserBindings" = @(
        @{
            "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
            "x509CertificateField" = "SubjectKeyIdentifier"
            "userProperty" = "certificateUserIds"
            "priority" = 1
        },
        @{
            "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
            "x509CertificateField" = "PrincipalName"
            "userProperty" = "UserPrincipalName"
            "priority" = 2
        },
        @{
            "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
            "x509CertificateField" = "RFC822Name"
            "userProperty" = "userPrincipalName"
            "priority" = 3
        }
    )
    "authenticationModeConfiguration" = @{
        "@odata.type" = "#microsoft.graph.x509CertificateAuthenticationModeConfiguration"
        "x509CertificateAuthenticationDefaultMode" = "x509CertificateMultiFactor"
        "rules" = @(
            @{
                "@odata.type" = "#microsoft.graph.x509CertificateRule"
                "x509CertificateRuleType" = "policyOID"
                "identifier" = "1.3.6.1.4.1.311.21.1"
                "x509CertificateAuthenticationMode" = "x509CertificateMultiFactor"
            }
        )
    }
    "includeTargets" = @(
        @{
            "targetType" = "group"
            "id" = $group.Id
            "isRegistrationRequired" = $false
        }
    ) } | ConvertTo-Json -Depth 5
    
  5. Execute a solicitação PATCH:
    Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate" -Body $body -ContentType "application/json"
    

Próximos passos