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

Sua organização pode implementar a autenticação moderna, resistente a phishing e sem senha usando certificação X.509 de usuários por meio da Autenticação Baseada em Certificado (CBA) do Microsoft Entra.

Neste artigo, saiba como configurar seu locatário 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 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 Microsoft Entra CBA para locatários em Office 365 Enterprise e planos 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 quaisquer ACs intermediárias são configuradas em Microsoft Entra ID.
  • 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 em Microsoft Entra ID.
  • Cada AC tem uma lista de certificados revogados (CRL) que pode ser referenciada a partir de URLs voltadas para a Internet. Se a AC confiável não tiver uma CRL configurada, Microsoft Entra ID 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.

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 práticas recomendadas para Microsoft Criptografia, incluindo a escolha de algoritmo, comprimento de chave e proteção de dados, consulte Microsoft recomendações. Use um dos algoritmos recomendados, um comprimento de chave recomendado e curvas aprovadas por NIST.

  • Como parte das melhorias contínuas de segurança, os terminais do Azure e 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. Os pontos de extremidade do Microsoft Entra que a CBA do Microsoft Entra usa estão incluídos 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. TLS 1.3 criptografa dados para fornecer um canal de comunicação seguro entre dois pontos finais. 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 de Microsoft Entra permite que os certificados emitidos por essas ACs autentiquem qualquer usuário no Microsoft Entra ID.

    É 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 Microsoft Entra CBA

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

Um administrador deve configurar as CAs confiáveis que emitem os certificados de usuário. Conforme mostrado no diagrama a seguir, 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

Microsoft recomenda que você use funções com menos 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 vinculações de nome de usuário mapeando o campo do certificado a 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 Microsoft Entra CBA no locatário.

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

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

O Microsoft Entra tem um novo repositório confiável de CAs baseado em PKI. O repositório confiável mantém as CAs 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 confiável baseado em PKI dá suporte a até 250 CAs e 8 KB para cada objeto de CA.

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 carregamento PKI do repositório de confiança baseado em PKI está disponível apenas com uma licença P1 ou P2 Microsoft Entra ID. No entanto, com o Microsoft Entra licença gratuita, 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 Autoridade Certificadora carregados.

Configurar as autoridades de certificação usando a Central 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 Privileged Authentication Administrator.

  2. Acesse Entra ID>Classificação de segurança de identidade>Infraestrutura de chave pública.

  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 de PKI

Para fazer upload de uma CA 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. Em URL da Lista de Revogação de Certificados, insira o URL disponível na Internet para a CRL base da CA 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. Em URL da Lista de Revogação de Certificado Delta, insira o URL voltado para a Internet para a CRL que contém todos os certificados revogados desde que a última CRL base foi publicada.

  6. Se a CA não precisar 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 exibidos 100 certificados de CA. 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 todas as CAs em um contêiner de PKI:

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

  2. Selecione Carregar PKI.

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

  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 CRL de CA carregado é atualizado com o primeiro URL HTTP disponível do certificado CA listado como o atributo de pontos de extremidade 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 CA, selecione ... e selecione Editar.
  2. Insira novos valores para o tipo de CA (raiz ou intermediária), o URL de CRL, o URL de CRL delta ou o sinalizador de dicas de emissor habilitado de acordo com seus requisitos.
  3. Selecione Salvar.

Editar em massa o atributo de dicas 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, em seguida, selecione Editar dicas do emissor.
  3. Marque a caixa de seleção Dicas do emissor ativadas para todas as CAs selecionadas ou desmarque a seleção para desativar o sinalizador Dicas do emissor ativadas para todas as CAs 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 Autoridade Certificadora

As dicas do emissor retornam um indicador de CA Confiável como parte do handshake de TLS (Transport Layer Security). A lista de CAs confiáveis é definida pela identidade das CAs que o locatário carrega no repositório confiável 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 de até 16 KB para as dicas do emissor (o nome da entidade da CA). Recomendamos que você defina o atributo isIssuerHintEnabled para 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 como true para CAs específicas, somente os certificados de usuário relevantes aparecerão no seletor de certificados.

Configurar as Autoridades Certificadoras (CAs) usando APIs do Microsoft Graph

Os exemplos a seguir mostram como usar 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 Certificados de Autoridade (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 CA específica em um PKI por ID de CA

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

Atualizar um sinalizador de dicas do emissor específico 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 Certificadoras (ACs) usando o PowerShell

Para essas etapas, use Microsoft Graph PowerShell.

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

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

    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 CA em um repositório de CAs baseado em PKI e em um repositório de CAs clássicas, o repositório confiável baseado em PKI será priorizado.

Um repositório de CAs clássicas é priorizado nestes cenários:

  • Há uma CA nos dois repositórios: o repositório baseado em PKI não possui CRL, mas a CA do repositório clássico tem uma CRL válida.
  • Uma CA está presente nos dois repositórios, e a CRL da CA do repositório baseado em PKI é diferente da CRL da CA do repositório clássico.

Log de entrada

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

  • É Usado no Repositório Legado tem um valor de 0, indicando 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 um log de entrada para usar um repositório baseado em PKI ou um repositório de CAs clássico

Log de auditoria

Todas as operações CRUD executadas em um PKI ou CA dentro do repositório confiável aparecem nos logs de auditoria do Microsoft Entra.

Captura de tela que mostra o painel Logs de Auditoria.

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

Um administrador de locatários pode carregar todas as CAs no repositório baseado em PKI. O repositório de PKI CA tem prioridade sobre um repositório clássico, e toda a autenticação de CBA ocorre por meio do repositório baseado em PKI. Um administrador de locatário pode remover as CAs de um repositório clássico ou legado depois de confirmar que não há indicação nos logs de entrada de que o repositório clássico ou legado 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 CA).

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 é 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 Microsoft Entra autenticação multifatorial.

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 atribuída pelo menos à função Authentication Policy Administrator.

  2. Vá para Grupos>Todos os grupos.

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

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

  5. Em Habilitar e Direcionar, selecione Habilitar e, em seguida, selecione a checkbox Eu Confirmo.

  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 inquilino, todos os usuários do inquilino 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 endpoint de autenticação de certificado para o ambiente de nuvem da organização, além do endpoint login.microsoftonline.com. Desative a inspeção de TLS no ponto de extremidade de autenticação de certificado para garantir que uma solicitação de certificado do cliente tenha sucesso como parte do handshake de TLS.

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

Uma política de associação de autenticação ajuda a definir se a força da autenticação será de um único fator ou 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 cliente é 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 diferente de proteção ou de associação por afinidade em relação ao padrão do tenant. 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 atribuída pelo menos à função Authentication Policy Administrator.

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

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

    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 vinculação de autenticação mapeiam os atributos do 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 vinculação de afinidade, 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 com o 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 vinculação de afinidade, selecione Baixo para vinculaçã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 da 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. Em Associação de afinidade, selecione Baixa.

    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. Autentique com um certificado que possui um OID de política 3.4.5.6 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 por CN=CBATestRootProd com uma OID de política de 1.2.3.4.6 precise apenas de 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 certificateUserIds e selecione Adicionar.

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

    4. Selecione Salvar.

      O log de entradas mostra qual associação foi usada para entrar, assim como 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 Principal no certificado para userPrincipalName no 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, onPremisesUserPrincipalName e o atributo userPrincipalName do objeto de usuário, contas que têm permissões administrativas no Windows Server Active Directory local poderão fazer alterações que afetam esses atributos no Microsoft Entra ID. 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 Microsoft Entra ID não encontrar um objeto de usuário que tenha um valor correspondente, a autenticação falhará. Em seguida, Microsoft Entra ID 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 principal do usuário (UPN).

    Captura de tela que mostra o nome principal 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.
  • Microsoft Entra ID está configurado 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 como o assunto da sua CA.

    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 principal de 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 vinculaçã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. Três associações são suportadas pela política de associação de nome de usuário.

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

Por padrão, Microsoft Entra ID mapeia Principal Name 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 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 de 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 do Assunto é:

Captura de tela mostrando o valor de 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 Entidade

O exemplo a seguir demonstra o mapeamento manual do assunto.

O valor do Assunto é:

Captura de tela que mostra outro valor do Assunto.

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 atribuída pelo menos à função Authentication Policy Administrator.

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

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

  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 de 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 exija associação de alta afinidade, os usuários do 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 o 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 vinculaçã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 de SKI correto do certificado e do 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 de SKI e se ele é solicitado a entrar usando MFA e o certificado.

Configurar a CBA usando APIs do Microsoft Graph

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

  1. Vá para Microsoft Graph Explorer.

  2. Selecione Entrar no Explorador do Graph e entre no 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 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"