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

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

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

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

Pré-requisitos

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

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

Importante

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

Importante

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

Importante

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

Nota

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

Etapas para configurar e testar o Microsoft Entra CBA

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

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

Etapa 1: Configurar as autoridades de certificação

Você pode configurar autoridades de certificação (CAs) usando o centro de administração do Microsoft Entra ou APIs REST do Microsoft Graph e os SDKs suportados, como o Microsoft Graph PowerShell. A infraestrutura PKI ou o administrador PKI deve ser capaz de fornecer a lista de autoridades de certificação emissoras. Para se certificar de que configurou todas as autoridades de certificação, abra o certificado de utilizador e clique no separador 'caminho de certificação' e certifique-se de que todas as autoridades de certificação até que a raiz seja carregada para o armazenamento fidedigno do Entra. A autenticação CBA falhará se houver CAs ausentes.

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

Para habilitar a autenticação baseada em certificado e configurar associações de usuário no centro de administração do Microsoft Entra, conclua as seguintes etapas:

1. Entre no centro de administração do Microsoft Entra como Administrador Global.

2. Navegue até Proteção>Mostrar mais>Autoridades de certificação da Central de Segurança (ou Pontuação Segura de Identidade). >

3. Para carregar uma autoridade de certificação, selecione Carregar:

   1. Selecione o arquivo CA.

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

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

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

   5. Selecione Adicionar.

      

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

5. Selecione Colunas para adicionar ou excluir colunas.

Nota

O carregamento de uma nova autoridade de certificação falhará se alguma autoridade de certificação existente expirar. Um Administrador Global deve excluir qualquer autoridade de certificação expirada e tentar carregar novamente a nova autoridade de certificação.

Configurar autoridades de certificação (CA) usando o PowerShell

Apenas um ponto de distribuição de CRL (CDP) para uma autoridade de certificação confiável é suportado. A CDP só pode ser HTTP URLs. Não há suporte para URLs OCSP (Online Certificate Status Protocol) ou LDAP (Lightweight Directory Access Protocol).

Para configurar suas autoridades de certificação no Microsoft Entra ID, para cada autoridade de certificação, carregue o seguinte:

• A parte pública do certificado, em formato .cer
• As URLs voltadas para a Internet onde residem as Listas de Revogação de Certificados (CRLs)

O esquema para uma autoridade de certificação tem a seguinte aparência:

    class TrustedCAsForPasswordlessAuth
    {
       CertificateAuthorityInformation[] certificateAuthorities;
    }

    class CertificateAuthorityInformation

    {
        CertAuthorityType authorityType;
        X509Certificate trustedCertificate;
        string crlDistributionPoint;
        string deltaCrlDistributionPoint;
        string trustedIssuer;
        string trustedIssuerSKI;
    }

    enum CertAuthorityType
    {
        RootAuthority = 0,
        IntermediateAuthority = 1
    }

Para a configuração, você pode usar o Microsoft Graph PowerShell:

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

2. Instale o Microsoft Graph PowerShell:

       Install-Module Microsoft.Graph
   

Como primeira etapa de configuração, você precisa estabelecer uma conexão com seu locatário. Assim que existir uma conexão com seu locatário, você poderá revisar, adicionar, excluir e modificar as autoridades de certificação confiáveis definidas em seu diretório.

Ligar

Para estabelecer uma conexão com seu locatário, use o Connect-MgGraph:

    Connect-MgGraph

Retrieve

Para recuperar as autoridades de certificação confiáveis definidas em seu diretório, use Get-MgOrganizationCertificateBasedAuthConfiguration.

    Get-MgOrganizationCertificateBasedAuthConfiguration

Adicionar

Nota

O carregamento de novas autoridades de certificação falhará quando qualquer uma das autoridades de certificação existentes expirar. O administrador do locatário deve excluir as autoridades de certificação expiradas e, em seguida, carregar a nova autoridade de certificação.

Siga as etapas anteriores para adicionar uma autoridade de certificação no centro de administração do Microsoft Entra.

Tipo de Autoridade

• Use 0 para indicar uma autoridade de certificação raiz
• Utilizar 1 para indicar uma autoridade de certificação intermédia ou emissora

crlDistributionPoint

Você pode baixar a CRL e comparar o certificado da autoridade de certificação e as informações da CRL para validar que o valor crlDistributionPoint no exemplo anterior do PowerShell é válido para a autoridade de certificação que você deseja adicionar.

A tabela e o gráfico a seguir mostram como mapear informações do certificado da autoridade de certificação para os atributos da CRL baixada.

Informações sobre o certificado da autoridade de certificação	=	Informações da CRL baixadas
Assunto	=	Emissor
Identificador de Chave do Requerente	=	Identificador de chave de autoridade (KeyID)

Gorjeta

O valor de crlDistributionPoint no exemplo anterior é o local http da CRL (Lista de Revogação de Certificados) da CA. Este valor pode ser encontrado em alguns lugares:

• No atributo CDP (Ponto de Distribuição de CRL) de um certificado emitido pela autoridade de certificação.

Se a autoridade de certificação emissora executar o Windows Server:

• Nas Propriedades da autoridade de certificação no MMC (Console de Gerenciamento Microsoft) da autoridade de certificação.
• Na AC executando certutil -cainfo cdp. Para obter mais informações, consulte certutil.

Para obter mais informações, consulte Noções básicas sobre o processo de revogação de certificados.

Validar a configuração da Autoridade de Certificação

É importante garantir que o resultado das etapas de configuração acima seja a capacidade do Entra ID de validar a cadeia de confiança da autoridade de certificação e obter com sucesso a lista de revogação de certificados (CRL) do ponto de distribuição de CRL (CDP) da autoridade de certificação configurada. Para ajudar com essa tarefa, é recomendável instalar o módulo PowerShell MSIdentity Tools e executar Test-MsIdCBATrustStoreConfiguration. Este cmdlet do PowerShell analisará a configuração da autoridade de certificação do locatário do Entra e os erros/avisos de superfície para problemas comuns de configuração incorreta.

Etapa 2: Habilitar o CBA no locatário

Importante

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

Para habilitar a autenticação baseada em certificado no centro de administração do Microsoft Entra, conclua as seguintes etapas:

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

2. Navegue até Grupos>Todos os grupos> selecionam Novo grupo e criam um grupo para usuários do CBA

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

4. Em Ativar e Destino, selecione Ativar.

5. Selecione Todos os usuários ou Adicionar grupos para selecionar grupos específicos, como o criado acima. Recomenda-se o uso de grupos específicos em vez de Todos os usuários.

   

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

Nota

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

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

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

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

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

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

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

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

   

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

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

   Nota

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

   

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

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

   Para adicionar regras personalizadas, selecione Adicionar regra.

   

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

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

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

      

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

   1. Insira um valor para Policy OID.

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

      

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

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

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

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

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

      

   5. Selecione Adicionar.

      

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

Importante

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

• Inscrição no Windows Hello para Empresas
• Registo da Chave de Segurança Fido2
• Login do Windows Passwordless Phone

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

• Edite as regras de política de autenticação baseada em certificado atualmente usando as opções Emissor e Política OID e remova o requisito Emissor ou OID e salve. OU
• Remova a regra de política de autenticação atualmente usando o OID do Emissor e da Política e crie regras usando apenas o OID do emissor ou da política

Estamos a trabalhar para corrigir o problema.

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

1. Adicione uma política de vinculação de autenticação que exija qualquer certificado emitido por CN=CBATestRootProd com policyOID 1.2.3.4.6 precisa apenas de vinculação de alta afinidade (ou seja, Emissor e número de série são usados).

   

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

   

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

   

4. Selecione Guardar.

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

1. Selecione Ok para salvar qualquer regra personalizada.

Importante

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

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

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

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

Para obter mais informações sobre cenários usando o atributo certificateUserIds, consulte IDs de usuário de certificado.

Importante

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

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

   

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

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

A configuração final será semelhante a esta imagem:

Etapa 5: Testar sua configuração

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

Teste o seu certificado

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

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

   

2. Selecione Seguinte.

   

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

   

3. Selecione Entrar com um certificado.

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

   

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

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

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

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

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

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

   CN = WoodgroveCA

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

   

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

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

   

5. Selecione Entrar com um certificado.

   

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

   

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

   

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

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

   

9. Selecione o certificado do cliente e selecione OK.

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

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

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

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

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

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

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

Antes de habilitar as novas associações, um Administrador de Política de Autenticação deve certificar-se de que os valores corretos para as associações sejam atualizados no atributo de objeto de usuário Certificate UserIds para as associações de nome de usuário correspondentes.

• Para usuários somente na nuvem, use o centro de administração do Microsoft Entra ou as APIs do Microsoft Graph para atualizar o valor em CertificateUserIds.
• Para usuários sincronizados locais, use o Microsoft Entra Connect para sincronizar os valores do local seguindo as regras do Microsoft Entra Connect ou sincronizando o valor AltSecId.

Importante

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

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

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

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

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

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

Por exemplo:

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

Aqui está um exemplo para o comando certutil:

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

X509 Certificate: 
Version: 3 
Serial Number: 48efa06ba8127299499b069f133441b2 

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

O valor SerialNumber a ser adicionado em CertificateUserId é:

B24134139F069B49997212A86BA0EF48

CertificateUserId:

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

Mapeamento manual de problemas e assuntos

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

O valor Subject é:

CertificateUserId:

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

Mapeamento manual do assunto

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

CertificateUserId:

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

Ligação de afinidade de teste

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

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

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

4. Selecione Configurar.

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

   Importante

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

   

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

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

8. Selecione SKI e selecione Adicionar.

   

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

   

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

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

11. Selecione Adicionar.

    

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

    

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

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

Habilitar o CBA usando a API do Microsoft Graph

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

Nota

As etapas a seguir usam o Graph Explorer, que não está disponível na nuvem do governo dos EUA. Os locatários de nuvem do governo dos EUA podem usar o Postman para testar as consultas do Microsoft Graph.

1. Vá para Microsoft Graph Explorer.

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

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

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

   GET  https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy
   

5. OBTENHA a configuração para o método de autenticação de certificado x509:

   GET https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy/authenticationMethodConfigurations/X509Certificate
   

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

   Corpo do pedido:

   PATCH https: //graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate
   Content-Type: application/json
   
   {
       "@odata.type": "#microsoft.graph.x509CertificateAuthenticationMethodConfiguration",
       "id": "X509Certificate",
       "state": "enabled",
       "certificateUserBindings": [
           {
               "x509CertificateField": "PrincipalName",
               "userProperty": "onPremisesUserPrincipalName",
               "priority": 1
           },
           {
               "x509CertificateField": "RFC822Name",
               "userProperty": "userPrincipalName",
               "priority": 2
           }, 
           {
               "x509CertificateField": "PrincipalName",
               "userProperty": "certificateUserIds",
               "priority": 3
           }
       ],
       "authenticationModeConfiguration": {
           "x509CertificateAuthenticationDefaultMode": "x509CertificateSingleFactor",
           "rules": [
               {
                   "x509CertificateRuleType": "issuerSubject",
                   "identifier": "CN=WoodgroveCA ",
                   "x509CertificateAuthenticationMode": "x509CertificateMultiFactor"
               },
               {
                   "x509CertificateRuleType": "policyOID",
                   "identifier": "1.2.3.4",
                   "x509CertificateAuthenticationMode": "x509CertificateMultiFactor"
               }
           ]
       },
       "includeTargets": [
           {
               "targetType": "group",
               "id": "all_users",
               "isRegistrationRequired": false
           }
       ]
   }
   

7. Você recebe um código de 204 No content resposta. Execute novamente a solicitação GET para garantir que as políticas sejam atualizadas corretamente.

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

Próximos passos

• Visão geral do Microsoft Entra CBA
• Aprofundamento técnico para Microsoft Entra CBA
• Limitações com o Microsoft Entra CBA
• Logon do Windows SmartCard usando o Microsoft Entra CBA
• Microsoft Entra CBA em dispositivos móveis (Android e iOS)
• IDs de usuário do certificado
• Como migrar usuários federados
• FAQ