Compartilhar via


Configurar a autenticação baseada em certificado do Microsoft Entra

Sua organização pode implementar autenticação sem senha, moderna e resistente a phishing por meio de certificados X.509 do usuário usando a CBA (autenticação baseada em certificado) do Microsoft Entra.

Neste artigo, saiba como configurar seu locatário do Microsoft Entra para permitir ou exigir que os usuários locatários se autentiquem usando certificados X.509. Um usuário cria um certificado X.509 usando uma PKI (infraestrutura de chave pública) corporativa para entrada de aplicativo e navegador.

Quando o Microsoft Entra CBA é configurado, durante a entrada, um usuário vê uma opção para autenticar usando um certificado em vez de inserir uma senha. Se vários certificados correspondentes estiverem localizados no dispositivo, o usuário selecionará o certificado relevante e o certificado será validado na conta de usuário. Se a validação for bem-sucedida, o usuário entrará.

Conclua as etapas descritas neste artigo para configurar e usar o Microsoft Entra CBA para locatários nos planos do Office 365 Enterprise e do Governo dos EUA. Você já deve ter uma PKI configurada.

Pré-requisitos

Verifique se os seguintes pré-requisitos estão em vigor.

  • Pelo menos uma AC (autoridade de certificação) e todas as ACs intermediárias estão configuradas na ID do Microsoft Entra.
  • O usuário tem acesso a um certificado de usuário emitido de uma PKI confiável configurada no locatário destinado à autenticação do cliente na ID do Microsoft Entra.
  • Cada AC tem uma CRL (lista de certificados revogados) que pode ser referenciada de URLs voltadas para a Internet. Se a CA confiável não tiver uma CRL configurada, o Microsoft Entra ID não executará as verificações de CRL, a revogação de certificados de usuário não funcionará e a autenticação não será bloqueada.

Considerações

  • Verifique se a PKI é segura e não pode ser facilmente comprometida. Se ocorrer uma violação, o invasor poderá criar e assinar certificados de cliente e comprometer qualquer usuário no locatário, incluindo usuários sincronizados do local. Uma estratégia de proteção de chave forte e outros controles físicos e lógicos podem fornecer defesa detalhada para impedir que invasores externos ou ameaças internas comprometam a integridade da PKI. Para obter mais informações, consulte Proteção da PKI.

  • Para obter as práticas recomendadas para a Criptografia da Microsoft, incluindo a escolha de algoritmo, comprimento da chave e proteção de dados, consulte as recomendações da Microsoft. Use um dos algoritmos recomendados, um comprimento de chave recomendado e curvas aprovadas por NIST.

  • Como parte de melhorias de segurança contínuas, os pontos de extremidade do Azure e do Microsoft 365 adicionaram suporte ao TLS 1.3. Espera-se que o processo leve alguns meses para cobrir os milhares de pontos de extremidade de serviço no Azure e no Microsoft 365. O ponto de extremidade do Microsoft Entra que o Microsoft Entra CBA usa 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 comumente implantado da Internet. O TLS 1.3 criptografa dados para fornecer um canal de comunicação seguro entre dois pontos de extremidade. Ele elimina algoritmos criptográficos obsoletos, aprimora a segurança em versões anteriores e criptografa o máximo possível do handshake. É altamente recomendável que você comece a testar o TLS 1.3 em seus aplicativos e serviços.

  • Quando você avalia uma PKI, é importante examinar as políticas de emissão de certificado e a imposição. Conforme descrito anteriormente, adicionar CAs a uma configuração do Microsoft Entra permite que os certificados emitidos por esses CAs autentiquem qualquer usuário na ID do Microsoft Entra.

    É importante considerar como e quando as ACs têm permissão para emitir certificados e como implementam identificadores reutilizáveis. Os administradores só precisam garantir que um certificado específico possa ser usado para autenticar um usuário, mas eles devem usar exclusivamente associações de alta afinidade para obter um nível mais alto de garantia de que apenas um certificado específico pode autenticar o usuário. Para obter mais informações, consulte Associações de alta afinidade.

Configurar e testar o Microsoft Entra CBA

Você deve concluir algumas etapas de configuração antes de ativar o Microsoft Entra CBA.

Um administrador deve configurar as CAs confiáveis que emitem os certificados de usuário. Conforme mostrado no diagrama a seguir, o Azure usa o RBAC (controle de acesso baseado em função) para garantir que apenas administradores com privilégios mínimos sejam obrigados a fazer alterações.

Importante

A Microsoft recomenda que você use funções com o menor número de permissões. Essa prática ajuda a melhorar a segurança da sua organização. 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, você pode configurar associações de autenticação para mapear certificados para autenticação de fator único ou MFA (autenticação multifator). Configure associações de nome de usuário para mapear o campo de certificado para um atributo do objeto de usuário. Um Administrador de Política de Autenticação pode definir configurações relacionadas ao usuário.

Quando todas as configurações forem concluídas, ative o Microsoft Entra CBA no locatário.

Diagrama que mostra uma visão geral das etapas necessárias para ativar a autenticação baseada em certificado do Microsoft Entra.

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

O Microsoft Entra tem um novo repositório de confiança de AC baseado em PKI. O repositório de confiança mantém as ACs dentro de um objeto de contêiner para cada PKI. Os administradores podem gerenciar as ACs em um contêiner com base na PKI com mais facilidade do que podem gerenciar uma lista simples de ACs.

O repositório de confiança baseado em PKI tem limites mais altos do que o repositório de confiança clássico para o número de CAs e o tamanho de cada arquivo de AC. Um repositório de confiança baseado em PKI dá suporte a até 250 CAs e 8 KB para cada objeto de AC.

Se você usar o repositório de confiança clássico para configurar as ACs, recomendamos que você configure um repositório de confiança baseado em PKI. O repositório de confiança baseado em PKI é escalonável e dá suporte a novas funcionalidades, como dicas de emissor.

Um administrador deve configurar as CAs confiáveis que emitem os certificados de usuário. Somente administradores com privilégios mínimos são necessários para fazer alterações. Um repositório de confiança baseado em PKI recebe a função administrador de autenticação com privilégios .

O recurso de upload PKI do repositório de confiança baseado em PKI está disponível apenas com uma licença P1 ou P2 da ID do Microsoft Entra. No entanto, com a licença gratuita do Microsoft Entra, um administrador pode carregar todos os CAs individualmente em vez de carregar um arquivo PKI. Em seguida, eles podem configurar o repositório de confiança baseado em PKI e adicionar seus arquivos de AC carregados.

Configurar CAs usando o Centro de administração do Microsoft Entra

Criar um objeto de contêiner PKI (Centro de administração do Microsoft Entra)

Para criar um objeto de contêiner PKI:

  1. Entre no Centro de administração do Microsoft Entra com uma conta atribuída à função administrador de autenticação com privilégios .

  2. Acesse ainfraestrutura de chave pública daClassificação> de Segurança de Identidade do Entra ID>.

  3. Selecione Criar PKI.

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

  5. Selecione Criar.

    Diagrama que mostra as etapas necessárias para criar uma PKI.

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

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

Excluir um objeto de contêiner de PKI

Para excluir uma PKI, selecione a PKI e selecione Excluir. Se a PKI contiver CAs, insira o nome da PKI para reconhecer a exclusão de todos os CAs na PKI. Em seguida, selecione Excluir.

Diagrama que mostra as etapas necessárias para excluir uma PKI.

Carregar CAs individuais em um objeto de contêiner PKI

Para carregar uma AC em um contêiner de PKI:

  1. Selecione Adicionar autoridade de certificação.

  2. Selecione o arquivo da AC.

  3. Se a AC for um certificado raiz, selecione Sim. Caso contrário, selecione Não.

  4. Para a URL da Lista de Revogação de Certificados, insira a URL voltada para a Internet para a CRL base da AC que contém todos os certificados revogados. Se a URL não estiver definida, uma tentativa de autenticação usando um certificado revogado não falhará.

  5. Para a URL da Lista de Revogação de Certificado Delta, insira 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. Se a AC não deve ser incluída nas dicas do emissor, desative as dicas do emissor. O sinalizador de dicas do Emissor está desativado por padrão.

  7. Selecione Salvar.

  8. Para excluir uma AC, selecione a AC e selecione Excluir.

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

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

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

Inicialmente, são mostrados 100 certificados de AC. Mais aparecem à medida que você rola para baixo no painel.

Carregar todos os CAs em um objeto de contêiner PKI

Para carregar em massa todos os CAs em um contêiner PKI:

  1. Crie um objeto de contêiner PKI ou abra um contêiner existente.

  2. Selecione Carregar PKI.

  3. Insira a URL voltada para a Internet HTTP do .p7b arquivo.

  4. Insira a soma de verificação SHA-256 do arquivo.

  5. Selecione o upload.

    O processo de upload de PKI é assíncrono. À medida que as ACs são carregadas, cada AC fica disponível na PKI. Todo o upload de PKI pode levar até 30 minutos.

  6. Selecione Atualizar para atualizar a lista de ACs.

  7. Cada atributo de ponto de extremidade de AC CRL carregado é atualizado com a primeira URL HTTP disponível do certificado de AC listada como o atributo de pontos de distribuição crl . Você deve atualizar manualmente todos os certificados folha.

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

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

Editar uma PKI

  1. Na linha PKI, selecione ... e selecione Editar.
  2. Insira um novo nome PKI.
  3. Selecione Salvar.

Editar uma AC

  1. Na linha ac, selecione ... e selecione Editar.
  2. Insira novos valores para o tipo de AC (raiz ou intermediária), a URL de CRL, a URL de CRL delta ou o sinalizador habilitado para dicas do emissor de acordo com seus requisitos.
  3. Selecione Salvar.

Editar em massa o atributo de dicas do emissor

  1. Para editar várias ACs e ativar ou desativar o atributo habilitado para dicas do Emissor , selecione várias ACs.
  2. Selecione Editar e, em seguida, selecione Editar dicas do emissor.
  3. Selecione a caixa de seleção habilitada para dicas do Emissor para todas as ACs selecionadas ou desmarque a seleção para desativar o sinalizador habilitado para dicas do Emissor para todas as ACs selecionadas. O valor padrão é indeterminado.
  4. Selecione Salvar.

Restaurar um PKI

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

Restaurar uma AC

  1. Selecione a aba CAs Excluídas.
  2. Selecione o arquivo de AC e, em seguida, selecione Restaurar autoridade de certificação.

Configurar o atributo isIssuerHintEnabled para uma AC

As dicas do emissor enviam de volta um indicador de AC confiável como parte do handshake TLS (Transport Layer Security). A lista de autoridades de certificação confiáveis é definida como o assunto dos CAs que o locatário carrega no repositório de confiança do Microsoft Entra. Para obter mais informações, consulte Noções básicas sobre dicas do emissor.

Por padrão, os nomes das entidades de todas as ACs no repositório confiável do Microsoft Entra são enviados na forma de dicas. Se você quiser enviar uma dica somente para CAs específicas, defina o atributo isIssuerHintEnabled de dica do emissor como true.

O servidor pode enviar de volta ao cliente TLS uma resposta máxima de 16 KB para as dicas do emissor (o nome da entidade da AC). Recomendamos que você defina o isIssuerHintEnabled atributo true apenas para as ACs que emitem certificados de usuário.

Se vários CAs intermediários do mesmo certificado raiz emitirem certificados de usuário, por padrão, todos os certificados aparecerão no seletor de certificado. Se você definir isIssuerHintEnabled para true CAs específicas, somente os certificados de usuário relevantes aparecerão no seletor de certificados.

Configurar as ACs usando APIs do Microsoft Graph

Os exemplos a seguir mostram como usar o Microsoft Graph para executar operações CRUD (Criar, Ler, Atualizar e Excluir) por meio de métodos HTTP para uma PKI ou AC.

Criar um objeto de contêiner PKI (Microsoft Graph)

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 um objeto PKI por ID PKI

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

Carregar CAs usando 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 CAs em um PKI

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

Obter uma AC específica em uma ID de autoridade de certificação de PKI

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

Atualizar um sinalizador específico de dicas do emissor da AC

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

Configurar as ACs usando o PowerShell

Para estas etapas, use o Microsoft Graph PowerShell.

  1. Inicie o PowerShell usando a opção Executar como 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>
    

Priorização entre um repositório de confiança baseado em PKI e um repositório de AC clássico

Se houver uma AC em um repositório de AC baseado em PKI e em um repositório de AC clássico, o repositório de confiança baseado em PKI será priorizado.

Um repositório de AC clássico é priorizado nestes cenários:

  • Existe uma AC em ambas as lojas, o repositório baseado em PKI não tem CRL, mas a AC da loja clássica tem uma CRL válida.
  • Existe uma AC em ambas as lojas, e a CRL de AC da loja baseada em PKI é diferente da CRL de AC da loja clássica.

Log de entrada

Uma entrada interrompida de log de entrada do Microsoft Entra tem dois atributos em Detalhes Adicionais para indicar se o repositório de confiança clássico ou herdado foi usado durante a autenticação.

  • O Repositório Herdado Usado tem um valor de 0 para indicar que um repositório baseado em PKI é usado. Um valor de 1 indica que um repositório clássico ou herdado é usado.
  • As Informações de Uso do Repositório Herdado exibem o motivo pelo qual o repositório clássico ou herdado é usado.

Captura de tela que mostra uma entrada de log de entrada para usar um repositório baseado em PKI ou um repositório de AC clássico

Log de auditoria

Todas as operações CRUD executadas em uma PKI ou AC dentro do repositório de confiança aparecem nos logs de auditoria do Microsoft Entra.

Captura de tela que mostra o painel Logs de Auditoria.

Migrar de um repositório de AC clássico para um repositório baseado em PKI

Um administrador de locatários pode carregar todos os CAs no repositório baseado em PKI. O repositório de AC PKI tem prioridade sobre um repositório clássico e toda a autenticação CBA ocorre por meio do repositório baseado em PKI. Um administrador de locatários pode remover as ACs de um repositório clássico ou herdado depois de confirmar nenhuma indicação nos logs de entrada de que o repositório clássico ou herdado foi usado.

Perguntas frequentes

Por que o carregamento de PKI falha?

Verifique se o arquivo PKI é válido e se ele pode ser acessado sem problemas. O tamanho máximo do arquivo PKI é de 2 MB (250 CAs e 8 KB para cada objeto de AC).

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

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

Como posso gerar uma soma de verificação SHA-256 para um arquivo PKI?

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

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

Etapa 2: Ativar a CBA para o locatário

Importante

Um usuário é considerado capaz de concluir a MFA quando o usuário é designado como no escopo da 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 usuário não tiver acesso a certificados, ele será bloqueado e não poderá registrar outros métodos para MFA. Os administradores que recebem a função administrador de política de autenticação devem ativar a CBA somente para usuários que têm certificados válidos. Não inclua Todos os usuários na CBA. Use apenas grupos de usuários que têm certificados válidos disponíveis. Para obter mais informações, consulte a autenticação multifator do Microsoft Entra.

Para ativar a CBA por meio do Centro de administração do Microsoft Entra:

  1. Entre no Centro de administração do Microsoft Entra com uma conta que recebe pelo menos a função administrador de política de autenticação .

  2. Vá para Grupos>Todos os grupos.

  3. Selecione Novo grupo e crie um grupo para usuários da CBA.

  4. Acesse osmétodos> de Autenticação de ID> do Entracom autenticação baseada em certificado.

  5. Em Habilitar e Direcionar, selecione Habilitar e, em seguida, selecione a caixa de seleção I Confirme .

  6. Escolha Selecionar grupos>Adicionar grupos.

  7. Escolha grupos específicos, como o que você criou e escolha Selecionar. Use grupos específicos em vez de Todos os usuários.

  8. Selecione Salvar.

    Captura de tela que mostra como ativar a CBA.

Depois que a CBA estiver ativada para o locatário, todos os usuários no locatário verão a opção de entrar usando um certificado. Somente usuários capazes de usar a CBA podem se autenticar usando um certificado X.509.

Observação

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

Etapa 3: Configurar uma política de associação de autenticação

Uma política de associação de autenticação ajuda a definir a força da autenticação como um único fator ou como MFA. O nível de proteção padrão para todos os certificados no locatário é a autenticação de fator único.

A associação de afinidade padrão no nível do locatário é de baixa afinidade. Um Administrador de Política de Autenticação pode alterar o valor padrão da autenticação de fator único para a MFA. Se o nível de proteção for alterado, todos os certificados no locatário serão definidos como MFA. Da mesma forma, a associação de afinidade no nível do locatário pode ser definida como alta afinidade. Todos os certificados são validados usando apenas atributos de alta afinidade.

Importante

Um administrador deve definir o padrão do locatário como um valor aplicável para a maioria dos certificados. Crie regras personalizadas apenas para certificados específicos que precisam de um nível de proteção ou associação de afinidade diferente do padrão do locatário. Todas as configurações do método de autenticação estão no mesmo arquivo de política. A criação de várias regras redundantes pode exceder o limite de tamanho do arquivo de política.

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

Para modificar as configurações de locatário padrão e criar regras personalizadas por meio do Centro de administração do Microsoft Entra:

  1. Entre no Centro de administração do Microsoft Entra com uma conta que recebe pelo menos a função administrador de política de autenticação .

  2. Vá parapolíticas de métodos> deAutenticaçãode ID> do Entra.

  3. Em Gerenciar migrações, selecioneautenticação baseada em certificadodos métodos> de autenticação.

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

  4. Para configurar a associação de autenticação e a associação de nome de usuário, selecione Configurar.

  5. Para alterar o valor padrão 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.

    Observação

    O nível de proteção padrão estará em vigor se nenhuma regra personalizada for adicionada. Se você adicionar uma regra personalizada, o nível de proteção definido no nível da regra será respeitado em vez do nível de proteção padrão.

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

  6. Você também pode configurar regras personalizadas de vinculação de autenticação para ajudar a determinar o nível de proteção dos certificados de cliente que precisam de valores diferentes para o nível de proteção ou vinculação de afinidade em relação ao padrão do locatário. Você pode configurar as regras usando o assunto do emissor ou a OID da política, ou ambos os campos, no certificado.

    As regras de associação de autenticação mapeiam os atributos de certificado (emissor ou OID de 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 a seguir, suponha que o padrão do locatário seja autenticação multifator e Baixa para associação de afinidade.

    Para adicionar regras personalizadas, selecione Adicionar regra.

    Captura de tela que mostra como adicionar uma regra personalizada.

    Para criar uma regra por emissor de certificado:

    1. Selecione o emissor do certificado.

    2. Para o identificador do emissor do certificado, selecione um valor relevante.

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

    4. Para associação affinity, selecione Baixo.

    5. Selecione Adicionar.

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

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

    Para criar uma regra por OID de política:

    1. Selecione OID da Política.

    2. Para o OID de Política, insira um valor.

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

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

    5. Selecione Adicionar.

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

      Captura de tela que mostra o mapeamento para o OID da política com uma associação de baixa afinidade.

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

    1. Selecione o emissor do certificado e o OID de política.

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

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

    4. Para associação affinity, selecione Baixo.

    5. Selecione Adicionar.

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

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

    6. Autenticar com um certificado que tem uma OID de 3.4.5.6 política e é emitido por CN=CBATestRootProd. Verifique se a autenticação é aprovada para uma declaração multifator.

    Para criar uma regra por emissor e número de série:

    1. Adicionar uma política de associação de autenticação. A política exige que qualquer certificado emitido com CN=CBATestRootProd uma OID de política precise apenas de 1.2.3.4.6 associação de alta afinidade. O emissor e o número de série são usados.

      Captura de tela que mostra o emissor e o número de série adicionados no Centro de administração do Microsoft Entra.

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

      Captura de tela que mostra como selecionar o Emissor e o número de série.

    3. O único atributo de usuário com suporte é certificateUserIds. Selecione e selecione certificateUserIdsAdicionar.

      Captura de tela que mostra como adicionar o Emissor e o número de série.

    4. Selecione Salvar.

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

      Captura de tela que mostra os detalhes do log de entrada.

  7. Selecione OK para salvar as regras personalizadas.

Importante

Insira o OID da política usando o formato do identificador de objeto. Por exemplo, se a política de certificado diz Todas as Políticas de Emissão, insira a OID da política como 2.5.29.32.0 quando você adicionar a regra. A cadeia de caracteres Todas as Políticas de Emissão é inválida para o editor de regras e não surtirá efeito.

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

A política de associação de nome de usuário ajuda a validar o certificado de um usuário. Por padrão, para determinar o usuário, você mapeia o Nome da Entidade de Segurança no certificado para userPrincipalName o objeto de usuário.

Um Administrador de Política de Autenticação pode substituir o padrão e criar um mapeamento personalizado. Para obter mais informações, consulte Como funciona a associação de nome de usuário.

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

Importante

Se uma política de associação de nome de usuário usar atributos sincronizados como certificateUserIds, onPremisesUserPrincipalNamee o userPrincipalName atributo do objeto de usuário, contas que têm permissões administrativas no Active Directory do Windows Server local poderão fazer alterações que afetam esses atributos na ID do Microsoft Entra. Por exemplo, contas que têm direitos delegados sobre objetos de usuário ou uma função de administrador no Microsoft Entra Connect Server podem fazer esses tipos de alterações.

  1. Crie a associação de nome de usuário selecionando um dos campos de certificado X.509 para associá-la a um dos atributos de usuário. A ordem de associação de nome de usuário representa o nível de prioridade da associação. A primeira associação de nome de usuário tem a prioridade mais alta e assim por diante.

    Captura de tela que mostra uma política de associação de nome de usuário.

    Se o campo de certificado X.509 especificado for encontrado no certificado, mas a ID do Microsoft Entra não encontrar um objeto de usuário que tenha um valor correspondente, a autenticação falhará. Em seguida, a ID do Microsoft Entra tenta a próxima associação na lista.

  2. Selecione Salvar.

Sua configuração final é semelhante a este exemplo:

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

Etapa 5: Teste sua configuração

Esta seção descreve como testar o certificado e as regras de associação de autenticação personalizadas.

Teste seu certificado

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

  1. Insira o nome da entidade de usuário (UPN).

    Captura de tela que mostra o nome da entidade de segurança do usuário.

  2. Selecione Avançar.

    Captura de tela que mostra uma entrada usando um certificado.

    Se você disponibilizou outros métodos de autenticação, como entrada por telefone ou FIDO2, os usuários poderão ver uma caixa de diálogo de entrada diferente.

    Captura de tela que mostra uma caixa de diálogo de entrada alternativa.

  3. Selecione Entrar com um certificado.

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

    Captura de tela que mostra a interface do usuário do seletor de certificado.

  5. Verifique se você está conectado ao portal do MyApps.

Se a entrada for bem-sucedida, você saberá que:

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

Testar regras de associação de autenticação personalizada

Em seguida, conclua um cenário no qual você valida a autenticação forte. Você cria duas regras de política de autenticação: uma usando um emissor sujeito a satisfazer a autenticação de fator único e outra usando o OID de política para satisfazer a autenticação multifator.

  1. Crie uma regra de assunto do emissor com um nível de proteção de autenticação de fator único. Defina o valor para o valor da entidade de autoridade de certificação.

    Por exemplo:

    CN=WoodgroveCA

  2. Crie uma regra OID de política que tenha um nível de proteção de autenticação multifator. Defina o valor como um dos OIDs de política em seu certificado. Um exemplo é 1.2.3.4.

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

  3. Crie uma política de Acesso Condicional do Microsoft Entra para que o usuário exija MFA. Conclua as etapas descritas no Acesso Condicional – Exigir MFA.

  4. Vá para o portal do MyApps. Insira seu UPN e selecione Avançar.

    Captura de tela que mostra o nome da entidade de segurança do usuário.

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

    Captura de tela que mostra a entrada usando um certificado.

    Se você disponibilizou outros métodos de autenticação, como conexão telefônica ou chaves de segurança, os usuários poderão ver uma caixa de diálogo de entrada diferente.

    Captura de tela que mostra a entrada alternativa.

  6. Selecione o certificado do cliente e, em seguida, selecione Informações do Certificado.

    Captura de tela que mostra o seletor de cliente.

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

    Captura de tela que mostra o emissor.

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

    Captura de tela 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 1.2.3.4 configurado e satisfaz a MFA. O emissor no certificado corresponde ao valor CN=WoodgroveCA configurado e satisfaz a autenticação de fator único.

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

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

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

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

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

Por padrão, a ID do Microsoft Entra mapeia o Nome da Entidade no certificado para userPrincipalName o 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 descrito anteriormente.

Um Administrador de Política de Autenticação deve configurar as novas associações. Para se preparar, eles devem garantir que os valores corretos para as associações de nome de usuário correspondentes sejam atualizados no certificateUserIds atributo do objeto de usuário:

Importante

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

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

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

O valor do Emissor a ser adicionado é:

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

Captura de tela que mostra o mapeamento manual do valor do Emissor.

Para obter o valor correto para o número de série, execute o comando a seguir. 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 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 ser adicionado 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 assunto

O exemplo a seguir demonstra o mapeamento manual do emissor e do assunto.

O valor do Emissor é:

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

O valor da Entidade é:

Captura de tela que mostra o valor da Entidade.

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 Entidade

O exemplo a seguir demonstra o mapeamento manual do assunto.

O valor da Entidade é:

Captura de tela que mostra outro valor da Entidade.

O certificateUserIds valor é:

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

Testar a associação de afinidade

  1. Entre no Centro de administração do Microsoft Entra com uma conta que recebe pelo menos a função administrador de política de autenticação .

  2. Vá parapolíticas de métodos> deAutenticaçãode ID> do Entra.

  3. Em Gerenciar, selecioneautenticação baseada em certificadodos métodos> de autenticação.

  4. Selecione Configurar.

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

    Importante

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

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

  6. Para testar, para Associação de Afinidade Necessária, selecione Baixo.

  7. Adicione uma associação de alta afinidade, como ski (identificador de chave de assunto). Em Associação de nome de usuário, selecione Adicionar regra.

  8. Selecione SKI e selecione Adicionar.

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

    Quando concluída, a regra é semelhante a este exemplo:

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

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

    Para obter mais informações, consulte padrões com suporte para CertificateUserIDs.

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

  11. Selecione Adicionar.

    Captura de tela que mostra uma associação de autenticação personalizada.

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

    Captura de tela que mostra uma regra personalizada.

  12. Atualize o valor do usuário certificateUserIds com o valor SKI correto do certificado e da OID de política de 9.8.7.5.

  13. Teste usando um certificado com o OID de política de 9.8.7.5. Verifique se o usuário está autenticado com a associação SKI e se ele foi solicitado a entrar com a MFA e apenas o certificado.

Configurar o CBA usando APIs do Microsoft Graph

Para configurar a CBA e configurar associações de nome de usuário usando APIs do Microsoft Graph:

  1. Vá para o Microsoft Graph Explorer.

  2. Selecione Entrar no Explorador do Graph e entre em seu locatário.

  3. Siga as etapas para consentir com a Policy.ReadWrite.AuthenticationMethod permissã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 de certificado X.509:

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

    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. Verifique se um 204 No content código de resposta é retornado. Execute novamente a solicitação GET para garantir que as políticas sejam atualizadas corretamente.

  8. Teste a configuração ao entrar com um certificado que atenda à política.

Configurar 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 a ser usada para definir um grupo para usuários da 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"