Configurar autenticação baseada em certificados Microsoft Entra

A sua organização pode implementar autenticação moderna, resistente a phishing e sem palavra-passe através de certificados X.509 de utilizador, utilizando autenticação baseada em certificados Microsoft Entra (CBA).

Neste artigo, aprenda como configurar o seu tenant Microsoft Entra para permitir ou exigir que os utilizadores de inquilinos se autentiquem usando certificados X.509. Um utilizador cria um certificado X.509 utilizando uma infraestrutura de chave pública empresarial (PKI) para iniciar sessão em aplicações e navegadores.

Quando o Microsoft Entra CBA é configurado, durante o início de sessão, o utilizador vê uma opção de autenticação usando um certificado em vez de introduzir uma palavra-passe. Se vários certificados correspondentes estiverem localizados no dispositivo, o utilizador seleciona o certificado relevante, e este é validado contra a conta do utilizador. Se a validação for bem-sucedida, o utilizador inicia sessão.

Complete os passos descritos neste artigo para configurar e utilizar o Microsoft Entra CBA para inquilinos em planos do Office 365 Enterprise e do Governo dos EUA. Deves já ter uma PKI configurada.

Pré-requisitos

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

  • Pelo menos uma autoridade certificadora (CA) e quaisquer CAs intermédias estão configuradas no Microsoft Entra ID.
  • O utilizador tem acesso a um certificado de utilizador emitido a partir de uma PKI de confiança configurada no inquilino destinado à autenticação do cliente no Microsoft Entra ID.
  • Cada CA tem uma lista de revogação de certificados (CRL) que pode ser referenciada a partir de URLs viradas para a internet. Se a CA de confiança não tiver uma CRL configurada, o Microsoft Entra ID não realiza qualquer verificação de CRL, a revogação dos certificados de utilizador não funciona e a autenticação não está bloqueada.

Considerações

  • Certifique-se de que a PKI é segura e que não pode ser facilmente comprometida. Se ocorrer uma violação, o atacante pode criar e assinar certificados de cliente e comprometer qualquer utilizador no inquilino, incluindo utilizadores sincronizados a partir das instalações. Uma estratégia forte de proteção de chaves e outros controlos físicos e lógicos podem proporcionar uma defesa em profundidade para evitar que atacantes externos ou ameaças internas comprometam a integridade da PKI. Para obter mais informações, consulte Protegendo PKI.

  • Para as melhores práticas para criptografia Microsoft, incluindo escolha do algoritmo, comprimento da chave e proteção de dados, consulte Microsoft recomendações. Certifique-se de usar um dos algoritmos recomendados, um comprimento de chave recomendado e curvas aprovadas pelo NIST.

  • Como parte das melhorias contínuas de segurança, os endpoints Azure e Microsoft 365 adicionaram suporte para TLS 1.3. Espera-se que o processo demore alguns meses para abranger os milhares de endpoints de serviço no Azure e no Microsoft 365. O Microsoft Entra endpoint que o Microsoft Entra CBA utiliza está incluído na atualização: *.certauth.login.microsoftonline.com e *.certauth.login.microsoftonline.us.

    O TLS 1.3 é a versão mais recente do protocolo de segurança mais utilizado na internet. O TLS 1.3 encripta dados para fornecer um canal de comunicação seguro entre dois pontos finais. Elimina algoritmos criptográficos obsoletos, melhora a segurança em relação às versões anteriores e encripta o máximo possível do handshake. Recomendamos vivamente que comece a testar o TLS 1.3 nas suas aplicações e serviços.

  • Ao avaliar uma PKI, é importante rever as políticas de emissão de certificados e a sua aplicação. Como descrito anteriormente, adicionar CAs a uma configuração do Microsoft Entra permite que certificados emitidos por essas CAs autentiquem qualquer utilizador no Microsoft Entra ID.

    É importante considerar como e quando as CAs podem emitir certificados e como implementam identificadores reutilizáveis. Os administradores só precisam de garantir que um certificado específico pode ser usado para autenticar um utilizador, mas devem usar exclusivamente ligações de alta afinidade para alcançar um nível mais elevado de garantia de que apenas um certificado específico pode autenticar o utilizador. Para mais informações, veja ligações de alta afinidade.

Configurar e testar o Microsoft Entra CBA

Deve completar alguns passos de configuração antes de ativar o Microsoft Entra CBA.

Um administrador deve configurar as autoridades de certificação confiáveis que emitem certificados de usuário. Como mostrado no diagrama seguinte, o Azure utiliza controlo de acesso baseado em funções (RBAC) para garantir que apenas os administradores com privilégios mínimos são obrigados a fazer alterações.

Importante

A Microsoft recomenda que use funções com o mínimo de permissões possível. Esta prática ajuda a melhorar a segurança da sua organização. Administrador Global é uma função altamente privilegiada que deve ser limitada a cenários de emergência ou quando você não pode usar uma função existente.

Opcionalmente, pode configurar ligações de autenticação para mapear certificados para autenticação de fator único ou para autenticação multifator (MFA). Configurar as associações de nome de utilizador para mapear o campo do certificado a um atributo do objeto de utilizador. Um Administrador de Políticas de Autenticação pode configurar definições relacionadas com o utilizador.

Quando todas as configurações estiverem concluídas, ative o Microsoft Entra CBA no inquilino.

Diagrama que mostra uma visão geral dos passos necessários para ativar a autenticação baseada em certificados Microsoft Entra.

Passo 1: Configurar as CAs com um repositório de confiança baseado em PKI

A Microsoft Entra tem uma nova loja fiduciária CA baseada em PKI. A trust store mantém as CAs dentro de um objeto contentor para cada PKI. Os administradores conseguem gerir CAs num contentor baseado em PKI mais facilmente do que gerir uma lista plana de CAs.

A loja de confiança baseada em PKI tem limites mais elevados do que a clássica loja de confiança para o número de CAs e o tamanho de cada ficheiro de CA. Um armazenamento de confiança baseado em PKI suporta até 250 CAs e 8 KB para cada objeto CA.

Se usar a clássica loja de confiança para configurar as CAs, recomendamos vivamente que configure uma loja de confiança baseada em PKI. A loja de confiança baseada em PKI é escalável e suporta novas funcionalidades, como dicas do emissor.

Um administrador deve configurar as autoridades de certificação confiáveis que emitem certificados de usuário. Apenas os administradores com privilégios mínimos são obrigados a fazer alterações. Um armazenamento de confiança, baseado em PKI, é-lhe atribuído o papel de Administrador de Autenticação Privilegiada.

A funcionalidade de upload PKI da loja de confiança baseada em PKI está disponível apenas com uma licença Microsoft Entra ID P1 ou P2. No entanto, com a licença gratuita Microsoft Entra, um administrador pode carregar todas as CAs individualmente em vez de carregar um ficheiro PKI. Depois, podem configurar a loja de confiança baseada em PKI e adicionar os ficheiros de CA carregados.

Configure as Autoridades de Certificação através do centro de administração do Microsoft Entra

Criar um objeto contentor PKI (centro de administração Microsoft Entra)

Para criar um objeto de contêiner PKI:

  1. Inicie sessão no centro de administração Microsoft Entra com uma conta atribuída à função Privileged Authentication Administrator.

  2. Vá a Entra ID>Identity Secure Score>Infraestrutura de chave pública.

  3. Selecione Criar PKI.

  4. Para Nome de Exibição, introduza um nome.

  5. Selecione Criar.

    Diagrama que mostra os passos necessários para criar uma PKI.

  6. Para adicionar ou eliminar colunas, selecione Editar colunas.

  7. Para atualizar a lista de PKIs, selecione Atualizar.

Excluir um objeto de contêiner PKI

Para excluir uma PKI, selecione a PKI e selecione Excluir. Se a PKI contiver CAs, insira o nome da PKI para confirmar a eliminação de todas as CAs na PKI. Em seguida, selecione Eliminar.

Diagrama que mostra os passos necessários para eliminar uma PKI.

Carregar CAs individuais para um container PKI

Para carregar uma CA para um contentor PKI:

  1. Selecionar Adicionar autoridade certificadora.

  2. Selecione o arquivo CA.

  3. Se a CA for um certificado raiz, selecione Sim. Caso contrário, selecione Sem.

  4. Para o URL da Lista de Revogação de Certificados, introduza a URL voltada para a internet para o CRL base da CA que contém todos os certificados revogados. Se o URL não estiver definido, uma tentativa de autenticação usando um certificado revogado não falha.

  5. Para o URL da Lista de Revogação de Certificados Delta, insira o URL acessível pela internet do CRL, que contém todos os certificados revogados desde a publicação do último CRL base.

  6. Se as dicas do emissor não devem incluir a CA, desative-as. A bandeira de dicas do Emissor está desligada por defeito.

  7. Selecione Guardar.

  8. Para eliminar uma CA, selecione a CA e selecione Eliminar.

    Diagrama que mostra como eliminar um certificado de CA.

  9. Para adicionar ou eliminar colunas, selecione Editar colunas.

  10. Para atualizar a lista de PKIs, selecione Atualizar.

Inicialmente, são apresentados 100 certificados de CA. Mais aparecem à medida que desces o painel.

Carregar todas as CAs para um objeto contentor PKI

Para carregar em massa todas as ACs para um contentor PKI:

  1. Crie um objeto contentor PKI ou abra um contentor existente.

  2. Selecione Carregar PKI.

  3. Introduza a URL HTTP da Internet voltada para o ficheiro .p7b.

  4. Introduza a soma de verificação SHA-256 do ficheiro.

  5. Selecione o carregamento.

    O processo de upload da PKI é assíncrono. À medida que cada CA é carregada, ela fica disponível na PKI. Todo o upload da PKI pode demorar até 30 minutos.

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

  7. Cada atributo de endpoint CRL CA carregado é atualizado com o primeiro URL HTTP disponível do certificado CA listado como um dos atributos de pontos de distribuição CRL. Deve atualizar manualmente quaisquer certificados de folha.

Para gerar a soma de verificação SHA-256 do ficheiro PKI .p7b , execute:

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

Editar uma PKI

  1. Na linha PKI, selecione ... e selecione Editar.
  2. Entra um novo nome PKI.
  3. Selecione Guardar.

Editar uma autoridade de certificação

  1. Na linha CA, selecione ... e selecione Editar.
  2. Introduza novos valores para o tipo de CA (raiz ou intermédia), o URL CRL, o URL delta CRL, ou o indicador de dicas ativadas do emissor de acordo com as suas necessidades.
  3. Selecione Guardar.

Editar em massa o atributo hints do emissor

  1. Para editar várias CAs e ativar ou desativar o atributo Dicas do Emissor ativadas, selecione várias CAs.
  2. Selecione Editar e depois selecione Editar dicas para emissores.
  3. Selecione a caixa de seleção de sugestões do emissor habilitada para todos os CAs selecionados ou desmarque a opção para desativar a flag de sugestões do emissor habilitada para todos os CAs selecionados. O valor padrão é Indeterminado.
  4. Selecione Guardar.

Restaurar uma PKI

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

Restaurar uma autoridade de certificação

  1. Selecione o separador CAs Eliminadas.
  2. Selecione o ficheiro CA e depois selecione Restaurar autoridade certificadora.

Configure o atributo isIssuerHintEnabled para uma CA

As indicações do emissor enviam de volta um indicador de CA confiável como parte do handshake do Transport Layer Security (TLS). A lista de CAs confiáveis está definida pela lista de CAs que o locatário carrega para o repositório de confiança da Microsoft Entra. Para mais informações, consulte Compreender dicas do emissor.

Por defeito, os nomes de assunto de todos as CAs no repositório de confiança da Microsoft Entra são enviados como pistas. Se quiser enviar uma dica apenas para CAs específicas, defina o atributo de indicação do emissor em isIssuerHintEnabled para true.

O servidor pode enviar de volta ao cliente TLS uma resposta máxima de 16 KB para as dicas do emissor (o nome do assunto da CA). Recomendamos que defina o isIssuerHintEnabled atributo apenas true para as CAs que emitem certificados de utilizador.

Se várias CAs intermédias do mesmo certificado raiz emitirem certificados de utilizador, por defeito, todos os certificados aparecem no seletor de certificados. Se definires isIssuerHintEnabled para true CAs específicas, só os certificados de utilizador relevantes aparecem no seletor de certificados.

Configure as Autoridades de Certificação utilizando as APIs do Microsoft Graph

Os exemplos seguintes mostram como usar o Microsoft Graph para executar operações de Crear, Ler, Atualizar e Eliminar (CRUD) através de métodos HTTP para uma PKI ou CA.

Criar um objeto contentor PKI (Microsoft Graph)

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

Obtenha todos os objetos PKI

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

Obtenha um objeto PKI pelo ID PKI

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-ID>/
ConsistencyLevel: eventual

Carregar certificados CA usando um ficheiro .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 numa PKI

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-ID>/certificateAuthorities
ConsistencyLevel: eventual

Obtenha uma CA específica numa PKI pelo ID da CA

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-ID>/certificateAuthorities/<CA-ID>
ConsistencyLevel: eventual

Atualize um indicador específico de dicas do emissor da CA

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

Configurar as Autoridades de Certificação utilizando o PowerShell

Para estes passos, use Microsoft Graph PowerShell.

  1. Inicia o PowerShell usando a opção Executar como administrador .

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

    Install-Module Microsoft.Graph -Scope AllUsers
    Import-Module Microsoft.Graph.Authentication
    Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
    
  3. Ligue-se ao inquilino e aceite todos:

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

Priorização entre uma loja de confiança baseada em PKI e uma loja clássica de CA

Se existir uma CA tanto numa loja baseada em PKI como numa loja de CA clássica, a loja de confiança baseada em PKI é prioritária.

Uma loja CA clássica é prioritária nestes cenários:

  • Existe uma CA em ambas as lojas, a loja baseada em PKI não tem CRL, mas a CA da loja clássica tem uma CRL válida.
  • Existe uma CA em ambas as lojas, e o CRL da loja baseado em PKI é diferente do CRL clássico da loja CA.

Registo de início de sessão

Uma entrada de registo interrompida no Microsoft Entra tem dois atributos sob Additional Details para indicar se o armazenamento de confiança clássico ou legado foi usado durante a autenticação.

  • A Loja Antiga Usada tem um valor 0 para indicar que uma loja baseada em PKI é utilizada. Um valor de 1 indica que é usada uma loja clássica ou antiga.
  • A Informação de Utilização da Loja Legada mostra a razão pela qual a loja clássica ou antiga é utilizada.

Captura de ecrã que mostra uma entrada de registo de login para usar uma loja baseada em PKI ou uma loja CA clássica

Registo de auditoria

Quaisquer operações CRUD que execute numa PKI ou CA dentro da trust store aparecem nos registos de auditoria da Microsoft Entra.

Captura de ecrã que mostra o painel de Registos de Auditoria.

Migrar de uma loja clássica da CA para uma loja baseada em PKI

Um administrador de tenant pode carregar todas as CAs para a loja baseada em PKI. A loja CA PKI tem então prioridade sobre uma loja clássica, e toda a autenticação CBA ocorre através da loja baseada em PKI. Um administrador de inquilinos pode remover as CAs de uma loja clássica ou antiga depois de confirmar que não há indicação nos registos de início de sessão de que a loja clássica ou legada foi utilizada.

Perguntas frequentes

Porque é que o upload da PKI falha?

Verifica se o ficheiro PKI é válido e que pode ser acedido sem problemas. O tamanho máximo do ficheiro PKI é de 2 MB (250 CAs e 8 KB para cada objeto CA).

Qual é o acordo de nível de serviço para o upload da PKI?

O upload do PKI é uma operação assíncrona e pode demorar até 30 minutos a ser concluído.

Como gero um checksum SHA-256 para um ficheiro PKI?

Para gerar o checksum SHA-256 do ficheiro PKI .p7b , execute este comando:

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

Passo 2: Ativar o CBA para o locatário

Importante

Um utilizador é considerado capaz de completar a MFA quando é designado como abrangido pela CBA na política de métodos de autenticação. Esse requisito de política significa que um usuário não pode usar a prova de identidade como parte de sua autenticação para registrar outros métodos disponíveis. Se o utilizador não tiver acesso aos certificados, fica bloqueado e não pode registar outros métodos para MFA. Os administradores atribuídos ao papel de Administrador da Política de Autenticação devem ativar o CBA apenas para utilizadores que tenham certificados válidos. Não inclua Todos os utilizadores para CBA. Use apenas grupos de utilizadores que tenham certificados válidos disponíveis. Para mais informações, consulte Microsoft Entra Autenticação Multi-Fatores.

Para ativar o CBA através do centro de administração Microsoft Entra:

  1. Inicie sessão no centro de administração Microsoft Entra com uma conta que esteja pelo menos atribuída ao papel Administrador da Política de Autenticação.

  2. Ir a Grupos>Todos os grupos.

  3. Selecione Novo grupo e crie um grupo para utilizadores de CBA.

  4. Vá a Entra ID>Métodos de autenticação>Autenticação baseada em certificado.

  5. Em Ativar e Direcionar, selecione Ativar e depois selecione a caixa Confirmo.

  6. Escolher Selecionar grupos>Adicionar grupos.

  7. Escolhe grupos específicos, como o que criaste, e depois escolhe Selecionar. Use grupos específicos em vez de Todos os utilizadores.

  8. Selecione Guardar.

    Captura de ecrã que mostra como ativar o CBA.

Depois de o CBA ser ativado para o inquilino, todos os utilizadores do tenant veem a opção de iniciar sessão usando um certificado. Apenas os utilizadores capazes de usar CBA podem autenticar-se usando um certificado X.509.

Nota

O administrador de rede deve permitir o acesso ao endpoint de autenticação de certificados para o ambiente cloud da organização, além do login.microsoftonline.com endpoint. Desligue a inspeção TLS no endpoint de autenticação do certificado para garantir que o pedido de certificado do cliente tem sucesso como parte do handshake TLS.

Passo 3: Configurar uma política de vinculação de autenticação

Uma política de vinculação de autenticação ajuda a definir a robustez da autenticação para um único fator ou para autenticação multifator (MFA). O nível de proteção padrão para todos os certificados no inquilino é a autenticação de fator único.

A ligação de afinidade padrão ao nível do locatário é de baixa afinidade. Um Administrador de Política de Autenticação pode alterar o valor predefinido de autenticação de fator único para MFA. Se o nível de proteção mudar, todos os certificados do locatário são configurados para MFA. De forma semelhante, a ligação de afinidade ao nível do inquilino pode ser definida para alta afinidade. Todos os certificados são então validados usando apenas atributos de alta afinidade.

Importante

Um administrador deve definir o valor padrão do tenant para um valor aplicável à maioria dos certificados. Crie regras personalizadas apenas para certificados específicos que necessitem de um nível de proteção ou de vinculação de afinidade diferente do padrão do locatário. Todas as configurações dos métodos de autenticação estão no mesmo ficheiro de políticas. Criar múltiplas regras redundantes pode exceder o limite de tamanho do ficheiro de políticas.

As regras de vinculação de autenticação mapeiam atributos de certificados como Emissor, ID de Objeto de Política (OID) e OID de Emissor e Política para um valor especificado. As regras definem o nível de proteção padrão e a ligação de afinidade para essa regra.

Para modificar as definições padrão de inquilino e criar regras personalizadas através do centro de administração Microsoft Entra:

  1. Inicie sessão no centro de administração Microsoft Entra com uma conta que esteja pelo menos atribuída ao papel Administrador da Política de Autenticação.

  2. Vá a Entra ID>Métodos de autenticação>Políticas.

  3. Em Gerir migrações, selecione Métodos de autenticação>Autenticação baseada em certificado.

    Captura de ecrã que mostra como definir uma política de autenticação.

  4. Para configurar a ligação de autenticação e a ligação de nome de utilizador, selecione Configurar.

  5. Para alterar o valor predefinido para MFA, selecione Autenticação Multifator. O atributo de nível de proteção tem um valor padrão de autenticação de fator único.

    Nota

    O nível de proteção padrão está em vigor se não forem adicionadas regras personalizadas. Se adicionares uma regra personalizada, o nível de proteção definido ao nível da regra é respeitado em vez do nível padrão de proteção.

    Captura de ecrã que mostra como mudar a política de autenticação padrão para MFA.

  6. Você também pode configurar regras de vinculação de autenticação personalizadas para determinar o nível de proteção para certificados de cliente que precisam de valores diferentes para nível de proteção ou vinculação de afinidade do que o padrão inicial. Pode configurar as regras utilizando o nome do emissor ou o OID da política, ou ambos os campos, no certificado.

    As regras de vinculação de autenticação mapeiam os atributos do certificado (OID da autoridade emissora ou da política) para um valor. O valor define o nível de proteção padrão para essa regra. Várias regras podem ser criadas. No exemplo seguinte, assuma que o cliente predefinido é autenticação multifator e Baixo para associação de afinidade.

    Para adicionar regras personalizadas, selecione Adicionar regra.

    Captura de ecrã que mostra como adicionar uma regra personalizada.

    Para criar uma regra pelo emissor do certificado:

    1. Selecione emissor de certificados.

    2. Para identificador de emissor de certificado, selecione um valor relevante.

    3. Para a força da autenticação, selecione autenticação multifator.

    4. Para ligação de afinidade, selecione Baixo.

    5. Selecione Adicionar.

    6. Quando solicitado, selecione a caixa de seleção Reconheço para adicionar a regra.

      Captura de ecrã que mostra como mapear uma política MFA para uma ligação de alta afinidade.

    Para criar uma regra por OID de política:

    1. Selecione o OID da Política.

    2. Para o OID da Política, introduza um valor.

    3. Para a força da autenticação, selecione Autenticação de fator único.

    4. Para ligação de afinidade, selecione Baixa para ligação de afinidade.

    5. Selecione Adicionar.

    6. Quando solicitado, selecione a caixa Reconheço para adicionar a regra.

      Captura de ecrã que mostra a associação ao OID da política com uma vinculação de baixa afinidade.

    Para criar uma regra por nome do emitente e OID da política:

    1. Selecione Emissor de Certificados e OID de Política.

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

    3. Para a força da autenticação, selecione autenticação multifator.

    4. Para ligação de afinidade, selecione Baixo.

    5. Selecione Adicionar.

      Captura de ecrã que mostra como selecionar uma ligação de baixa afinidade.

      Captura de ecrã que mostra como adicionar uma ligação de baixa afinidade.

    6. Autentique com um certificado que tenha um OID de política de 3.4.5.6 e seja emitido por CN=CBATestRootProd. Verifique se a autenticação é bem-sucedida para uma reivindicação de múltiplos fatores.

    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 exige que qualquer certificado emitido por CN=CBATestRootProd com um OID de política de 1.2.3.4.6 necessite apenas de vinculação de alta afinidade. O emissor e o número de série são utilizados.

      Captura de ecrã que mostra o emissor e número de série adicionados na centro de administração Microsoft Entra.

    2. Selecione o campo de certificado. Para este exemplo, selecione Emissor e número de série.

      Captura de ecrã que mostra como selecionar o emissor e o número de série.

    3. O único atributo de utilizador suportado é certificateUserIds. Selecione certificateUserIds e selecione Adicionar.

      Captura de ecrã que mostra como adicionar o emissor e o número de série.

    4. Selecione Guardar.

      O registo de início de sessão mostra qual a vinculação foi utilizada para o início de sessão e os detalhes do certificado.

      Captura de ecrã que mostra os detalhes do registo de sessão.

  7. Seleciona OK para guardar quaisquer regras personalizadas.

Importante

Introduza o OID da política usando o formato do identificador de objeto. Por exemplo, se a política de certificados disser Todas as Políticas de Emissão, introduza o OID da política como 2.5.29.32.0 quando adiciona 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.

Passo 4: Configurar a política de ligação de nome de utilizador

A política de vinculação de nomes de utilizador ajuda a validar o certificado do utilizador. Por defeito, para determinar o utilizador, mapeia-se o Nome Principal no certificado para o objeto de utilizador userPrincipalName.

Um administrador de política de autenticação pode substituir o padrão e criar um mapeamento personalizado. Para mais informações, veja Como funciona a atribuição de nomes de utilizador.

Para outros cenários que utilizam o certificateUserIds atributo, veja IDs de utilizador de certificados.

Importante

Se uma política de ligação de nomes de utilizador usar atributos sincronizados como certificateUserIds, onPremisesUserPrincipalName e o atributo userPrincipalName do objeto utilizador, contas que tenham permissões administrativas em Windows Server Active Directory on-premises podem fazer alterações que afetem esses atributos em Microsoft Entra ID. Por exemplo, contas que tenham direitos delegados sobre objetos de utilizador ou um papel de administrador no Microsoft Entra Connect Server podem fazer este tipo de alterações.

  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. A vinculação do primeiro nome de utilizador tem a prioridade mais alta, e assim sucessivamente.

    Captura de ecrã que mostra uma política vinculativa 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 utilizador com valor correspondente, a autenticação falha. Depois, Microsoft Entra ID tenta a próxima associação na lista.

  2. Selecione Guardar.

A sua configuração final é semelhante a este exemplo:

Captura de ecrã que mostra a configuração final.

Etapa 5: Testar sua configuração

Esta secção descreve como testar o seu certificado e as regras de autenticação personalizadas.

Teste o seu certificado

No primeiro teste de configuração, tente iniciar sessão no portal MyApps usando o navegador do seu dispositivo.

  1. Introduza o seu nome principal de utilizador (UPN).

    Captura de ecrã que mostra o nome principal do utilizador.

  2. Selecione Seguinte.

    Captura de ecrã que mostra um login usando um certificado.

    Se disponibilizasse outros métodos de autenticação, como login por telefone ou FIDO2, os seus utilizadores poderiam ver um diálogo de login diferente.

    Captura de ecrã que mostra um diálogo alternativo para iniciar sessão.

  3. Selecione Entrar com um certificado.

  4. Selecione o certificado de utilizador correto na interface do seletor de certificados do cliente e selecione OK.

    Captura de ecrã que mostra a interface do seletor de certificados.

  5. Verifica se estás ligado ao portal MyApps.

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

  • O certificado de utilizador é provisionado no seu dispositivo de teste.
  • O Microsoft Entra ID está configurado corretamente para usar CAs de confiança.
  • A atribuição de nomes de utilizador está configurada corretamente. O utilizador é encontrado e autenticado.

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

De seguida, conclua um cenário em que valida uma autenticação forte. Criam-se duas regras de política de autenticação: uma usando um sujeito emissor para satisfazer a autenticação de um único fator, e outra usando o OID da política para satisfazer a autenticação multifator.

  1. Crie uma regra sujeita ao emissor com um nível de proteção de autenticação de um único fator. Defina o valor para o valor sujeito da sua CA.

    Por exemplo:

    CN=WoodgroveCA

  2. Crie uma regra de política OID com um nível de proteção de autenticação multifator. Defina o valor para um dos OIDs da apólice no seu certificado. Um exemplo é 1.2.3.4.

    Captura de ecrã que mostra a regra de OID da política.

  3. Crie uma política Acesso Condicional do Microsoft Entra para que o utilizador precise de MFA. Complete os passos descritos em Acesso Condicional - Requer MFA.

  4. Vai ao portal MyApps. Introduza o seu UPN e selecione Seguinte.

    Captura de ecrã que mostra o nome principal do utilizador.

  5. Selecione Usar um certificado ou cartão inteligente.

    Captura de ecrã que mostra o início de sessão usando um certificado.

    Se disponibilizasse outros métodos de autenticação, como login no telemóvel ou chaves de segurança, os seus utilizadores poderiam ver um diálogo de login diferente.

    Captura de ecrã que mostra o login alternativo.

  6. Selecione o certificado do cliente e depois selecione Informação do Certificado.

    Captura de ecrã que mostra o selecionador de clientes.

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

    Captura de ecrã que mostra o emissor.

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

    Captura de ecrã que mostra os detalhes da autenticação.

  8. Selecione o certificado do cliente e selecione OK.

O OID da política no certificado corresponde ao valor configurado de 1.2.3.4 e satisfaz MFA. O emissor do certificado coincide com o valor configurado de CN=WoodgroveCA e cumpre o critério de autenticação de fator simples.

Como a regra OID da política tem precedência sobre a regra do emissor, o certificado satisfaz MFA.

A política de Acesso Condicional para o utilizador requer MFA e o certificado satisfaz MFA, pelo que o utilizador pode iniciar sessão na aplicação.

Teste a política de vinculação de nomes de utilizador

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

  • IssuerAndSerialNumber > certificateUserIds
  • IssuerAndSubject > certificateUserIds
  • Subject > certificateUserIds

Por defeito, Microsoft Entra ID mapeia Principal Name no certificado para userPrincipalName no objeto utilizador para determinar o utilizador. Um Administrador de Política de Autenticação pode sobrepor o padrão e criar um mapeamento personalizado conforme descrito anteriormente.

Um Administrador de Política de Autenticação deve configurar as novas ligações. Para se prepararem, devem garantir que os valores corretos para as associações de nomes de utilizador correspondentes são atualizados no certificateUserIds atributo do objeto utilizador:

Importante

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

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

O exemplo seguinte demonstra o mapeamento manual do emissor e do número de série.

O valor do Emissor a acrescentar é:

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

Captura de ecrã que mostra o mapeamento manual do valor do Emissor.

Para obter o valor correto do número de série, execute o seguinte comando. 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 do certutil comando:

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 do número de série a adicionar certificateUserId é:

b24134139f069b49997212a86ba0ef48

O certificateUserIds valor é:

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

Mapeamento manual do emissor e do sujeito

O exemplo seguinte demonstra o mapeamento manual do emissor e do sujeito.

O valor do Emissor é:

Captura de ecrã que mostra o valor do Emissor quando usado com múltiplas ligações.

O valor Sujeito é:

Captura de ecrã que mostra o valor do assunto.

O certificateUserId valor é:

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 de tópicos

O exemplo seguinte demonstra o mapeamento manual de assuntos.

O valor Sujeito é:

Captura de ecrã que mostra outro valor de Assunto.

O certificateUserIds valor é:

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

Testar a ligação de afinidade

  1. Inicie sessão no centro de administração Microsoft Entra com uma conta que esteja pelo menos atribuída ao papel Administrador da Política de Autenticação.

  2. Vá a Entra ID>Métodos de autenticação>Políticas.

  3. Em Gerir, 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 abrangente para todos os arrendatários. Podes bloquear o tenant inteiro se alterares o valor de Associação de Afinidade Requerida para o tenant e não tiveres os valores corretos no objeto de utilizador. De forma semelhante, se criares uma regra personalizada que se aplique a todos os utilizadores e exija ligação de alta afinidade, os utilizadores no tenant podem ficar bloqueados.

    Captura de ecrã que mostra como definir a ligação de afinidade necessária.

  6. Para testar, para Ligação de Afinidade Obrigatória, selecione Baixo.

  7. Adicione uma ligação de alta afinidade, como o identificador de chave de assunto (SKI). No campo de Associação de Nome de Utilizador, selecione Adicionar regra.

  8. Selecione SKI e selecione Adicionar.

    Captura de ecrã que mostra como adicionar uma ligação de afinidade.

    Quando terminado, a regra assemelha-se a este exemplo:

    Captura de ecrã que mostra uma ligação de afinidade concluída.

  9. Para todos os objetos de utilizador, atualize o certificateUserIds atributo com o valor SKI correto do certificado de utilizador.

    Para obter mais informações, consulte Padrões suportados para CertificateUserIDs.

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

  11. Selecione Adicionar.

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

    Verifique se a regra concluída é semelhante a este exemplo:

    Captura de ecrã que mostra uma regra personalizada.

  12. Atualize o valor certificateUserIds do utilizador com o valor SKI correto extraído do certificado e o OID da política de 9.8.7.5.

  13. Teste usando um certificado com OID de política de 9.8.7.5. Verifique se o utilizador está autenticado com a ligação SKI e que foi solicitado a iniciar sessão com MFA e apenas com o certificado.

Configure o CBA usando APIs Microsoft Graph

Para configurar o CBA e vinculações de nomes de utilizador utilizando as APIs do Microsoft Graph:

  1. Vai a Microsoft Graph Explorer.

  2. Selecione Iniciar sessão no Graph Explorer e iniciar sessão com o seu inquilino.

  3. Siga os passos para consentir a Policy.ReadWrite.AuthenticationMethod autorização delegada.

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

    GET  https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy
    
  5. Obtenha a configuração do método de autenticação do certificado X.509:

    GET https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy/authenticationMethodConfigurations/X509Certificate
    
  6. Por defeito, o método de autenticação do certificado X.509 está desligado. Para permitir que os utilizadores iniciem sessão usando um certificado, deve ativar o método de autenticação e configurar as políticas de autenticação e de ligação de nomes de utilizador através de uma operação de atualização. Para atualizar a política, faça uma PATCH requisição.

    Corpo da solicitação

    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. Verifica se um 204 No content código de resposta é devolvedo. Repete o GET pedido para garantir que as políticas estão atualizadas corretamente.

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

Configurar CBA com o Microsoft PowerShell

  1. Abra o PowerShell.

  2. Liga-te ao Microsoft Graph:

    Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"
    
  3. Crie uma variável para usar na definição de um grupo para utilizadores de CBA:

    $group = Get-MgGroup -Filter "displayName eq 'CBATestGroup'"
    
  4. Defina o corpo do pedido:

    $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. Executar a PATCH requisição:

    Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate" -Body $body -ContentType "application/json"