Partilhar via

Aprofundamento técnico técnico de autenticação baseada em certificado Microsoft Entra

  • Artigo

Este artigo explica como funciona a autenticação baseada em certificado (CBA) do Microsoft Entra e mergulha em detalhes técnicos sobre as configurações do Microsoft Entra CBA.

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

A imagem a seguir descreve o que acontece quando um usuário tenta entrar em um aplicativo em um locatário onde o Microsoft Entra CBA está habilitado.

Ilustração com etapas sobre como funciona a autenticação baseada em certificado do Microsoft Entra.

Agora vamos percorrer cada etapa:

  1. O usuário tenta acessar um aplicativo, como o portal MyApps.

  2. Se o usuário ainda não estiver conectado, ele será redirecionado para a página de entrada do usuário do Microsoft Entra ID em https://login.microsoftonline.com/.

  3. O usuário insere seu nome de usuário na página de entrada do Microsoft Entra e seleciona Avançar. O Microsoft Entra ID faz a descoberta do território doméstico usando o nome do locatário e o nome de usuário é usado para procurar o usuário no locatário.

    Captura de ecrã do portal Iniciar sessão para MyApps.

  4. O Microsoft Entra ID verifica se o CBA está habilitado para o locatário. Se o CBA estiver habilitado, o usuário verá um link para Usar um certificado ou cartão inteligente na página de senha. Se o usuário não vir o link de entrada, verifique se o CBA está habilitado no locatário. Para obter mais informações, consulte Como habilitar o Microsoft Entra CBA?.

    Nota

    Se o CBA estiver habilitado no locatário, todos os usuários verão o link para Usar um certificado ou cartão inteligente na página de senha. No entanto, somente os usuários no escopo do CBA podem autenticar com êxito em um aplicativo que usa o Microsoft Entra ID como seu provedor de identidade (IdP).

    Captura de ecrã da secção Utilizar um certificado ou cartão inteligente.

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

    Captura de ecrã do início de sessão se FIDO2 também estiver ativado.

  5. Depois que o usuário seleciona a autenticação baseada em certificado, o cliente é redirecionado para o ponto de extremidade certauth, que é https://certauth.login.microsoftonline.com para ID pública do Microsoft Entra. Para o Azure Government, o ponto de extremidade certo é https://certauth.login.microsoftonline.us.

    O ponto de extremidade executa a autenticação mútua TLS e solicita o certificado do cliente como parte do handshake TLS. Uma entrada para essa solicitação aparece no log de entrada.

    Nota

    O administrador de rede deve permitir o acesso à página de início de sessão do utilizador e ao ponto de extremidade *.certauth.login.microsoftonline.com certo para o ambiente de nuvem do cliente. 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.

    Certifique-se de que a desativação da inspeção TLS também funcione para a nova url com dicas do emissor. Não codifice a url com tenantId porque ela pode mudar para usuários B2B. Use uma expressão regular para permitir que a URL antiga e a nova funcionem para a desativação da inspeção TLS. Por exemplo, dependendo do proxy, use *.certauth.login.microsoftonline.com ou *certauth.login.microsoftonline.com. No Azure Government, use *.certauth.login.microsoftonline.us ou *certauth.login.microsoftonline.us.

    A menos que o acesso seja permitido, a autenticação baseada em certificado falhará se você habilitar as dicas do emissor.

  6. O Microsoft Entra ID solicita um certificado de cliente. O usuário escolhe o certificado do cliente e seleciona Ok.

    Captura de tela do seletor de certificados.

  7. O Microsoft Entra ID verifica a lista de revogação de certificados para garantir que o certificado não foi revogado e é válido. O ID do Microsoft Entra identifica o usuário usando a associação de nome de usuário configurada no locatário para mapear o valor do campo de certificado para o valor do atributo do usuário.

  8. Se um usuário exclusivo for encontrado com uma política de Acesso Condicional que exija autenticação multifator e a regra de vinculação de autenticação de certificado satisfizer a MFA, a ID do Microsoft Entra assinará o usuário imediatamente. Se a MFA for necessária, mas o certificado satisfizer apenas um único fator, o login sem senha ou FIDO2 será oferecido como um segundo fator se eles já estiverem registrados.

  9. O Microsoft Entra ID conclui o processo de entrada enviando um token de atualização primário de volta para indicar a entrada bem-sucedida.

  10. Se o login do usuário for bem-sucedido, o usuário poderá acessar o aplicativo.

Noções básicas sobre dicas do emissor (Visualização)

As dicas do emissor enviam de volta uma Indicação de CA Confiável como parte do handshake TLS. A lista de CAs confiáveis é definida como assunto das Autoridades de Certificação (CAs) carregadas pelo locatário no repositório confiável do Entra. Um cliente de navegador ou cliente de aplicativo nativo pode usar as dicas enviadas de volta pelo servidor para filtrar os certificados mostrados no seletor de certificados. O cliente mostra apenas os certificados de autenticação emitidos pelas autoridades de certificação no armazenamento confiável.

Ativar dicas do emissor

Para ativar, clique na caixa de seleção Dicas do emissor. Política de autenticação Os administradores devem clicar em Reconheço depois de se certificarem de que o proxy com inspeção TLS habilitada está atualizado corretamente e salvar.

Nota

Se sua organização tiver firewalls ou proxies com inspeção TLS, reconheça que você desativou a inspeção TLS do ponto de extremidade certauth capaz de corresponder a qualquer nome em [*.]certauth.login.microsoftonline.com, personalizado de acordo com o proxy específico em uso.

Captura de tela de como habilitar dicas do emissor.

Nota

A URL da autoridade de certificação terá um formato t{tenantId}.certauth.login.microsoftonline.com depois que as dicas do emissor forem habilitadas.

Captura de tela do seletor de certificados depois que as dicas do emissor são habilitadas.

Propagação de atualização do armazenamento confiável da CA

Depois de habilitar as dicas do emissor e adicionar, atualizar ou excluir CAs do estado de confiança, há um atraso de até 10 minutos para propagar as dicas do emissor de volta ao cliente. Os usuários não podem se autenticar com certificados emitidos pelas novas autoridades de certificação até que as dicas sejam propagadas.

Política de autenticação Os administradores devem entrar com um certificado depois de habilitar as dicas do emissor para iniciar a propagação. Os usuários verão a mensagem de erro abaixo quando as atualizações do armazenamento confiável da autoridade de certificação estiverem em propagação.

Captura de tela de um erro que os usuários veem se as atualizações estão em andamento.

MFA com autenticação baseada em certificado de fator único

O Microsoft Entra CBA é suportado como primeiro fator e fator selcond para autenticação. Algumas das combinações suportadas são:

  1. ACB (primeiro fator) e chaves de acesso (segundo fator)
  2. CBA (primeiro fator) e login por telefone sem senha (segundo fator)
  3. Chaves de segurança CBA (primeiro fator) e FIDO2 (segundo fator)
  4. Senha (primeiro fator) + CBA (segundo fator) (Visualização)

Nota

CBA como um segundo fator no iOS tem problemas conhecidos e está bloqueado no iOS. Estamos trabalhando para corrigir os problemas e devemos ser suportados no iOS.

Os usuários precisam ter uma maneira de obter MFA e registrar login sem senha ou FIDO2 antes de entrar com o Microsoft Entra CBA.

Importante

Um usuário é considerado capaz de MFA quando eles são incluídos nas configurações do método CBA. Isso significa que o usuário não pode usar a prova como parte de sua autenticação para registrar outros métodos disponíveis. Verifique se os usuários sem um certificado válido não estão incluídos nas configurações do método CBA. Para obter mais informações sobre como a autenticação funciona, consulte Autenticação multifator do Microsoft Entra.

Opções para obter a capacidade de MFA com certificados de fator único

O Microsoft Entra CBA é capaz de autenticação multifator (MFA). O Microsoft Entra CBA pode ser de fator único (SF) ou multifator (MF), dependendo da configuração do locatário. Habilitar o CBA torna um usuário potencialmente capaz de concluir o MFA. Um usuário com certificado de fator único precisará de outro fator para concluir o MFA. Se o usuário não tiver nenhum outro método de autenticação registrado e for adicionado ao escopo do método de autenticação CBA, o usuário não poderá comprovar o registro de outros métodos de autenticação.

Se o usuário habilitado para CBA tiver apenas um certificado de fator único (SF) e precisar concluir a MFA:

  1. Use uma senha e um certificado SF.
  2. Emita um Passe de Acesso Temporário.
  3. O Administrador da Política de Autenticação adiciona um número de telefone e permite a autenticação de voz/mensagem de texto para a conta de usuário.

Se o usuário habilitado para CBA ainda não recebeu um certificado e precisa concluir o MFA:

  1. Emita um Passe de Acesso Temporário.
  2. O Administrador da Política de Autenticação adiciona um número de telefone e permite a autenticação de voz/mensagem de texto para a conta de usuário.

Se o usuário habilitado para CBA não puder usar um certificado MF, como em um dispositivo móvel sem suporte a cartão inteligente, e precisar concluir o MFA:

  1. Emita um Passe de Acesso Temporário.
  2. O usuário precisa registrar outro método MFA (quando o usuário pode usar o certificado MF).
  3. Use senha e MF cert (quando o usuário pode usar MF cert).
  4. O Administrador da Política de Autenticação adiciona um número de telefone e permite a autenticação de voz/mensagem de texto para a conta de usuário.

Etapas para configurar o login por telefone sem senha (PSI) com CBA

Para que o início de sessão sem palavra-passe funcione, os utilizadores devem desativar a notificação herdada através da sua aplicação móvel.

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

  2. Siga os passos em Ativar autenticação de início de sessão por telemóvel sem palavra-passe.

    Importante

    Na configuração anterior, certifique-se de que escolheu a opção Sem palavra-passe . Você precisa alterar o modo de autenticação para todos os grupos adicionados para PSI para sem senha. Se você escolher Qualquer, CBA e PSI não funcionam.

  3. Selecione Proteção>Autenticação>multifator Configurações adicionais de autenticação multifator baseadas em nuvem.

    Captura de tela de como definir configurações de autenticação multifator.

  4. Em Opções de verificação, desmarque Notificação através da aplicação móvel e selecione Guardar.

    Captura de ecrã de como remover notificações através da aplicação móvel.

Fluxo de autenticação MFA usando certificados de fator único e login sem senha

Vejamos um exemplo de um usuário que tem certificado de fator único e está configurado para entrada sem senha.

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

    Captura de ecrã de como introduzir um nome principal de utilizador.

  2. Selecione Entrar com um certificado.

    Captura de ecrã de como iniciar sessão com um certificado.

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

    Captura de ecrã da forma alternativa de iniciar sessão com um certificado.

  3. Escolha o certificado de usuário correto no seletor de certificados do cliente e selecione OK.

    Captura de tela de como selecionar um certificado.

  4. Como o certificado está configurado para ser força de autenticação de fator único, o usuário precisa de um segundo fator para atender aos requisitos de MFA. O usuário vê disponíveis segundos fatores, que neste caso é o login sem senha. Selecione Aprovar uma solicitação no meu aplicativo Microsoft Authenticator.

    Captura de tela da solicitação de segundo fator.

  5. Você receberá uma notificação no seu telefone. Selecione Aprovar login?. Captura de ecrã do pedido de aprovação.

  6. Introduza o número que vê no ecrã do browser ou da aplicação no Microsoft Authenticator.

    Captura de ecrã da correspondência de números.

  7. Selecione Sim e o usuário pode autenticar e entrar.

Noções básicas sobre a política de vinculação de autenticação

A política de associação de autenticação ajuda a determinar a força da autenticação como fator único ou multifator. Os administradores de política de autenticação podem alterar o valor padrão de fator único para multifator, ou configurar configurações de diretiva personalizadas usando o assunto do emissor ou os campos OID de política ou Emissor e Política no certificado.

Pontos fortes do certificado

Os administradores de políticas de autenticação podem determinar se os certificados são de fator único ou força multifator. Para obter mais informações, consulte a documentação que mapeia os níveis de garantia de autenticação do NIST para os métodos de autenticação do Microsoft Entra, que se baseia no NIST 800-63B SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Mgmt.

Autenticação de certificado multifator

Quando um usuário tem um certificado multifator, ele pode executar a autenticação multifator somente com certificados. No entanto, um administrador de política de autenticação deve certificar-se de que os certificados estão protegidos com um PIN ou biométrico para serem considerados multifator.

Como o Microsoft Entra ID resolve várias regras de vinculação de política de autenticação

Como várias regras de política de vinculação de autenticação personalizada podem ser criadas com diferentes campos de certificado, como o uso de emissor + OID de política, ou apenas OID de política ou apenas emissor. Abaixo estão as etapas usadas para determinar o nível de proteção de autenticação quando as regras personalizadas se sobrepõem. São os seguintes:

  1. As regras OID de emissor + política têm precedência sobre as regras de OID de política. As regras OID da política têm precedência sobre as regras do emissor do certificado.
  2. As regras OID do emissor + da política são avaliadas primeiro. Se você tiver uma regra personalizada com o emissor CA1 e a política OID 1.2.3.4.5 com MFA, somente o certificado A satisfaz o valor do emissor e o OID da política receberão MFA.
  3. Em seguida, as regras personalizadas usando OIDs de política são avaliadas. Se você tiver um certificado A com a política OID 1.2.3.4.5 e uma credencial derivada B baseada nesse certificado tiver uma política OID 1.2.3.4.5.6, e a regra personalizada for definida como Policy OID com o valor 1.2.3.4.5 com MFA, somente o certificado A satisfará a MFA e a credencial B satisfará apenas a autenticação de fator único. Se o usuário usou credencial derivada durante o login e foi configurado para ter MFA, o usuário será solicitado para um segundo fator para autenticação bem-sucedida.
  4. Se houver um conflito entre vários OIDs de política (como quando um certificado tem dois OIDs de política, em que um se liga à autenticação de fator único e o outro se liga à MFA), trate o certificado como uma autenticação de fator único.
  5. Em seguida, as regras personalizadas usando a autoridade de certificação do emissor são avaliadas.
  6. Se um certificado tiver regras de política OID e Emissor correspondentes, o OID de política será sempre verificado primeiro e, se nenhuma regra de política for encontrada, as associações do emissor serão verificadas. O Policy OID tem uma prioridade de vinculação de autenticação forte mais alta do que o emissor.
  7. Se uma autoridade de certificação se vincular à MFA, todos os certificados de usuário emitidos pela autoridade de certificação serão qualificados como MFA. A mesma lógica se aplica à autenticação de fator único.
  8. Se um OID de política se ligar ao MFA, todos os certificados de usuário que incluem esse OID de política como um dos OIDs (um certificado de usuário pode ter vários OIDs de política) qualificam-se como MFA.
  9. Um emissor de certificado só pode ter uma ligação de autenticação forte válida (ou seja, um certificado não pode ser vinculado a um fator único e a MFA).

Importante

Há um problema conhecido em que um Administrador de Política de Autenticação do Microsoft Entra configura uma regra de política de autenticação CBA usando o Emissor e o OID de 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, ID do Microsoft Entra e ingresso de dispositivo híbrido do Microsoft Entra não é afetado. As regras da política de autenticação CBA usando o Emissor OU o OID da Política não são afetadas. Para atenuar, os Administradores de Política de Autenticação 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.

Noções básicas sobre 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, o Nome Principal do Nome Alternativo da Entidade (SAN) no certificado é mapeado para o atributo UserPrincipalName do objeto de usuário para determinar o usuário.

Obtenha maior segurança com associações de certificados

Há sete métodos suportados para associações de certificado. Em geral, os tipos de mapeamento são considerados de alta afinidade se forem baseados em identificadores que não podem ser reutilizados, como Identificadores de Chave de Assunto ou Chave Pública SHA1. Esses identificadores transmitem uma maior garantia de que apenas um único certificado pode ser usado para autenticar o respetivo usuário.

Os tipos de mapeamento baseados em nomes de usuário e endereços de e-mail são considerados de baixa afinidade. O Microsoft Entra ID implementa três mapeamentos considerados de baixa afinidade com base em identificadores reutilizáveis. Os outros são considerados ligações de alta afinidade. Para obter mais informações, consulte certificateUserIds.

Campo de mapeamento de certificado Exemplos de valores em certificateUserIds Atributos do objeto do usuário Type
NomePrincipal X509:<PN>bob@woodgrove.com userPrincipalName
onPremisesUserPrincipalName
certificateUserIds		 baixa afinidade
RFC822Nome X509:<RFC822>user@woodgrove.com userPrincipalName
onPremisesUserPrincipalName
certificateUserIds		 baixa afinidade
IssuerAndSubject (pré-visualização) X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest certificateUserIds baixa afinidade
Assunto (pré-visualização) X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest certificateUserIds baixa afinidade
ESQUI X509:<SKI>aB1cD2eF3gH4iJ5kL6-mN7oP8qR= certificateUserIds alta afinidade
SHA1Chave Pública X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR certificateUserIds alta afinidade
IssuerAndSerialNumber (pré-visualização) X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
Para obter o valor correto para o número de série, execute este comando e armazene o valor mostrado em CertificateUserIds:
Sintaxe:
Certutil –dump –v [~certificate path~] >> [~dumpFile path~]
Exemplo:
certutil -dump -v firstusercert.cer >> firstCertDump.txt		 certificateUserIds alta afinidade

Definir vinculação de afinidade no nível do locatário e substituir por regras personalizadas (Visualização)

Com esse recurso, um administrador de política de autenticação pode configurar se um usuário pode ser autenticado usando mapeamento de vinculação de nome de usuário de baixa ou alta afinidade. Você pode definir a vinculação de afinidade necessária para o locatário, que se aplica a todos os usuários. Você também pode substituir o valor padrão de todo o locatário criando regras personalizadas com base em Emissor e OID de Política, ou OID de Política ou Emissor.

Como o Microsoft Entra ID resolve várias regras de vinculação de política de nome de usuário

Use a vinculação de prioridade mais alta (número mais baixo).

  1. Procure o objeto de usuário usando o nome de usuário ou Nome Principal do Usuário.
  2. Obtenha a lista de todas as associações de nome de usuário configuradas pelo Administrador de Política de Autenticação na configuração do método de autenticação CBA ordenada pelo atributo 'priority'. Hoje o conceito de prioridade não está exposto no Portal UX. O gráfico retornará o atributo de prioridade para cada vinculação e eles são usados no processo de avaliação.
  3. Se o locatário tiver a vinculação de alta afinidade habilitada ou se o valor do certificado corresponder a uma regra personalizada que exigiu associação de alta afinidade, remova todas as associações de baixa afinidade da lista.
  4. Avalie cada associação na lista até que ocorra uma autenticação bem-sucedida.
  5. Se o campo de certificado X.509 da associação configurada estiver no certificado apresentado, a ID do Microsoft Entra corresponderá o valor no campo de certificado ao valor do atributo de objeto do usuário.
    1. Se uma correspondência for encontrada, a autenticação do usuário será bem-sucedida.
    2. Se uma correspondência não for encontrada, passe para a próxima vinculação de prioridade.
  6. Se o campo de certificado X.509 não estiver no certificado apresentado, passe para a próxima vinculação de prioridade.
  7. Valide todas as associações de nome de usuário configuradas até que uma delas resulte em uma correspondência e a autenticação do usuário seja bem-sucedida.
  8. Se uma correspondência não for encontrada em nenhuma das associações de nome de usuário configuradas, a autenticação do usuário falhará.

Protegendo a configuração do Microsoft Entra com várias associações de nome de usuário

Cada um dos atributos de objeto de usuário do Microsoft Entra (userPrincipalName, onPremiseUserPrincipalName, certificateUserIds) disponíveis para vincular certificados a contas de usuário do Microsoft Entra tem uma restrição exclusiva para garantir que um certificado corresponda apenas a uma única conta de usuário do Microsoft Entra. No entanto, o Microsoft Entra CBA oferece suporte a vários métodos de vinculação na política de vinculação de nome de usuário que permite que um Administrador de Política de Autenticação acomode um certificado para várias configurações de contas de usuário do Microsoft Entra.

Importante

Se você configurar várias associações, a autenticação CBA do Microsoft Entra será tão segura quanto a vinculação de menor afinidade porque o CBA validará cada associação para autenticar o usuário. Para evitar um cenário em que um único certificado corresponde a várias contas do Microsoft Entra, um Administrador de Política de Autenticação pode:

  • Configure um único método de associação na política de vinculação de nome de usuário.
  • Se um locatário tiver vários métodos de associação configurados e não quiser permitir que um certificado seja mapeado para várias contas, o Administrador de Política de Autenticação deverá garantir todos os métodos permitidos configurados no mapa de políticas para a mesma conta do Microsoft Entra. Todas as contas de usuário devem ter valores correspondentes a todas as associações.
  • Se um locatário tiver vários métodos de associação configurados, o Administrador de Política de Autenticação deverá certificar-se de que ele não tenha mais de uma associação de baixa afinidade.

Por exemplo, vamos supor que você tenha duas associações de nome de usuário em PrincipalName mapeado para UPN e SubjectKeyIdentifier (SKI) para certificateUserIds. Se você quiser que um certificado seja usado apenas para uma única conta, um Administrador de Política de Autenticação deve certificar-se de que a conta tem o UPN presente no certificado e implementar o mapeamento SKI no atributo certificateUserId da mesma conta.

Suporte para vários certificados com uma conta de usuário do Microsoft Entra (M:1)

Há cenários em que uma organização emite vários certificados para uma única identidade. Mais comumente, isso pode ser uma credencial derivada para um dispositivo móvel ou também pode ser para um cartão inteligente secundário ou dispositivo capaz de titular de credenciais x509, como um Yubikey.

Contas somente na nuvem: Para contas somente na nuvem, você pode mapear vários certificados (até 5) para uso preenchendo o campo certificateUserIds (Informações de autorização no Portal do Usuário) com valores exclusivos que identificam cada certificado. Se a organização estiver usando ligações de alta afinidade, digamos Issuer + SerialNumber, os valores em CertificateUserIds podem ter a seguinte aparência:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

Neste exemplo, o primeiro valor representa X509Certificate1 e o segundo valor representa X509Certificate2. O usuário pode apresentar qualquer certificado no início de sessão e, desde que a Vinculação de Nome de Usuário CBA esteja definida para apontar para o campo certificateUserIds para procurar o tipo de associação específico (ou seja, Emissor+SerialNumber neste exemplo), o usuário entrará com êxito.

Contas híbridas sincronizadas Para contas sincronizadas, você pode mapear vários certificados para uso preenchendo o campo altSecurityIdentities no AD os valores que identificam cada certificado. Se a organização estiver usando ligações de alta afinidade (ou seja, autenticação forte), digamos Emissor + SerialNumber, isso pode ter a seguinte aparência:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

Neste exemplo, o primeiro valor representa X509Certificate1 e o segundo valor representa X509Certificate2. Esses valores devem ser sincronizados com o campo certificateUserIds no Microsoft Entra ID.

Suporte para um certificado com várias contas de usuário do Microsoft Entra (1:M)

Há cenários em que uma organização precisa que o usuário use o mesmo certificado para autenticar em várias identidades. Mais comumente, isso é para contas administrativas. Também pode ser para contas de desenvolvedor ou contas de serviço temporário. No AD tradicional, o campo altSecurityIdentities é usado para preencher os valores do certificado e uma Dica é usada durante o login para direcionar o AD para a conta desejada para verificar o login. Com o Microsoft Entra CBA isso é diferente e não há Dica. Em vez disso, o Home Realm Discovery identifica a conta desejada para verificar os valores do certificado. A outra diferença importante é que o Microsoft Entra CBA impõe exclusividade no campo certificateUserIds. Isso significa que duas contas não podem preencher os mesmos valores de certificado.

Importante

Não é uma configuração muito segura usar a mesma credencial para autenticar em diferentes contas do Microsoft Entra e recomenda-se não permitir um certificado para várias contas de usuário do Microsoft Entra.

Contas somente na nuvem Para contas somente na nuvem, você precisa criar várias associações de nome de usuário e mapear valores exclusivos para cada conta de usuário que utilizará o certificado. Cada conta será autenticada usando uma associação de nome de usuário diferente. Isso se aplica dentro do limite de um único diretório/locatário (ou seja, os Administradores de Política de Autenticação também podem mapear o certificado para uso em outro diretório/locatário, desde que os valores permaneçam exclusivos por conta também).

Preencha o campo certificateUserIds (Informações de autorização no Portal do Usuário) com um valor exclusivo que identifique o certificado desejado. Se a organização estiver usando ligações de alta afinidade (ou seja, autenticação forte), as ligações dizem Emissor + SerialNumber e SKI, isso pode ter a seguinte aparência:

Ligações de nome de usuário:

  • Emissor + Número de Série -> CertificateUserIds
  • SKI -> CertificateUserIds

Valores CertificateUserIds da conta de usuário:
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>aB1cD2eF3gH4iJ5kL6-mN7oP8qR
X509:<SKI>cD2eF3gH4iJ5kL6mN7-oP8qR9sT

Agora, quando um usuário apresenta o mesmo certificado no login, o usuário entrará com êxito porque sua conta corresponde a um valor exclusivo nesse certificado. Uma conta será autenticada usando Issuer+SerialNumber e a outra usando a vinculação SKI.

Nota

O número de contas que podem ser usadas dessa maneira é limitado pelo número de associações de nome de usuário configuradas no locatário. Se a organização estiver usando apenas associações de alta afinidade, o número de contas suportadas será limitado a 3. Se a organização também estiver utilizando ligações de baixa afinidade, esse número aumentará para 7 contas (1 PrincipalName, 1 RFC822Name, 1 SubjectKeyIdentifier, 1 SHA1PublicKey, 1 Issuer+Subject, 1 Issuer+SerialNumber, 1 Subject).

Contas sincronizadas híbridas Para contas sincronizadas, a abordagem será diferente. Embora os Administradores de Política de Autenticação possam mapear valores exclusivos para cada conta de usuário que utilizará o certificado, a prática comum de preencher todos os valores para cada conta no Microsoft Entra ID tornaria isso difícil. Em vez disso, o Microsoft Entra Connect deve filtrar os valores desejados por conta para valores exclusivos preenchidos na conta na ID do Microsoft Entra. A regra de exclusividade se aplica dentro do limite de um único diretório/locatário (ou seja, os Administradores de Política de Autenticação também podem mapear o certificado para uso em outro diretório/locatário, desde que os valores permaneçam exclusivos por conta também). Além disso, a organização pode ter várias florestas do AD contribuindo com usuários em um único locatário do Microsoft Entra. Nesse caso, o Microsoft Entra Connect aplicará o filtro a cada uma dessas florestas do AD com o mesmo objetivo de preencher apenas um valor exclusivo desejado para a conta de nuvem.

Preencha o campo altSecurityIdentities no AD com os valores que identificam o certificado desejado e inclua o valor de certificado desejado para esse tipo de conta de usuário (como detailee, admin, developer e assim por diante). Selecione um atributo de chave no AD que informará à sincronização qual tipo de conta de usuário o usuário está avaliando (como msDS-cloudExtensionAttribute1). Preencha esse atributo com o valor de tipo de usuário desejado, como detailee, admin ou developer. Se esta for a conta principal do usuário, o valor pode ser deixado vazio/nulo.

As contas podem ter a seguinte aparência:

Floresta 1 - Conta1 (bob@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Floresta 1 - Conta2 (bob-admin@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Floresta 2 – ADAccount1 (bob-tdy@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Esses valores devem ser sincronizados com o campo certificateUserIds no Microsoft Entra ID.

Etapas para sincronizar com certificateUserIds

  1. Configure o Microsoft Entra Connect para adicionar o campo alternativeSecurityIds ao Metaverso
  2. Para cada Floresta do AD, configure uma nova regra de entrada personalizada com uma precedência alta (número baixo abaixo de 100). Adicione uma transformação Expression com o campo altSecurityIdentities como origem. A expressão de destino usará o Atributo de Chave que você selecionou e preencheu, bem como o mapeamento para os Tipos de Usuário que você definiu.
  3. Por exemplo:
IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer"))>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    Where($item,[altSecurityIdentities],(BitAnd(InStr($item, "X509:<I>"),InStrRev($item, "<SR>"))>0)), NULL) 
)

No exemplo acima, altSecurityIdentities e o atributo de chave msDS-cloudExtensionAttribute1is são verificados primeiro para ver se estão preenchidos. Caso contrário, altSecurityIdentities é verificado para ver se está preenchido. Se estiver vazio, então nós o definimos como NULL. Caso contrário, a conta cai no caso padrão e, neste exemplo, filtramos apenas para o mapeamento Issuer+SerialNumber. Se o atributo key for preenchido, o valor será verificado para ver se é igual a um dos nossos tipos de usuário definidos. Neste exemplo, se esse valor for detailee, filtraremos para o valor SHA1PublicKey de altSecurityIdentities. Se o valor for desenvolvedor, filtraremos para o valor SubjectKeyIssuer de altSecurityIdentities. Pode haver vários valores de certificado de um tipo específico. Por exemplo, vários valores PrincipalName ou vários valores SKI ou SHA1-PUKEY. O filtro obterá todos os valores e sincronizará com o Microsoft Entra ID – não apenas o primeiro que encontrar.

  1. Um segundo exemplo que mostra como enviar por push um valor vazio se o atributo de controle estiver vazio está abaixo.
IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer")>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    AuthoritativeNull, NULL) 
)

Se o valor em altSecurityIdentities não corresponder a nenhum dos valores de pesquisa no atributo de controle, um AuthoritativeNull será passado. Isso garante que as regras anteriores ou subsequentes que preenchem alternativeSecurityId sejam ignoradas e o resultado fique vazio no Microsoft Entra ID.

  1. Configure uma nova regra de saída personalizada com uma precedência baixa (número alto acima de 160 – parte inferior da lista).
  2. Adicione uma transformação direta com o campo alternativeSecurityIds como origem e o campo certificateUserIds como destino.
  3. Execute um ciclo de sincronização para concluir o preenchimento dos dados no Microsoft Entra ID.

Certifique-se de que o CBA em cada locatário esteja configurado com as Ligações de Nome de Usuário apontando para o campo certificateUserIds para os tipos de campo mapeados a partir do certificado. Agora, qualquer um desses usuários pode apresentar o certificado no início de sessão e, depois que o valor exclusivo do certificado for validado em relação ao campo certificateUserIds, esse usuário será conectado com êxito.

Noções básicas sobre o processo de revogação de certificados

O processo de revogação de certificados permite que os Administradores de Política de Autenticação revoguem um certificado emitido anteriormente de ser usado para autenticação futura. A revogação do certificado não revogará tokens já emitidos pelo usuário. Siga as etapas para revogar manualmente os tokens em Configurar revogação.

O Microsoft Entra ID baixa e armazena em cache a lista de revogação de certificados (CRL) dos clientes de sua autoridade de certificação para verificar se os certificados são revogados durante a autenticação do usuário.

Os administradores de políticas de autenticação podem configurar o ponto de distribuição de CRL durante o processo de instalação dos emissores confiáveis no locatário do Microsoft Entra. Cada emissor confiável deve ter uma CRL que possa ser referenciada usando uma URL voltada para a Internet.

Importante

O tamanho máximo de uma CRL para o Microsoft Entra ID ser baixado com êxito em um logon interativo e cache é de 20 MB no Microsoft Entra ID público e 45 MB nas nuvens do Azure US Government e o tempo necessário para baixar a CRL não deve exceder 10 segundos. Se o Microsoft Entra ID não puder baixar uma CRL, as autenticações baseadas em certificados que usam certificados emitidos pela autoridade de certificação correspondente falharão. Como prática recomendada, manter os arquivos CRL dentro dos limites de tamanho, manter a vida útil dos certificados dentro de limites razoáveis e limpar certificados expirados. Para obter mais informações, consulte Existe um limite para o tamanho da CRL?.

Quando um usuário executa uma entrada interativa com um certificado e a CRL excede o limite interativo para uma nuvem, sua entrada inicial falha com o seguinte erro:

"A lista de revogação de certificados (CRL) baixada de {uri} excedeu o tamanho máximo permitido ({size} bytes) para CRLs no Microsoft Entra ID. Tente novamente em poucos minutos. Se o problema persistir, entre em contato com os administradores do locatário."

Após o erro, o Microsoft Entra ID tenta baixar a CRL sujeita aos limites do lado do serviço (45 MB na ID pública do Microsoft Entra e 150 MB nas nuvens do Azure US Government).

Importante

Se um Administrador de Política de Autenticação ignorar a configuração da CRL, o Microsoft Entra ID não executará nenhuma verificação de CRL durante a autenticação baseada em certificado do usuário. Isso pode ser útil para a solução de problemas iniciais, mas não deve ser considerado para uso em produção.

A partir de agora, não oferecemos suporte ao Protocolo de Status de Certificado Online (OCSP) por motivos de desempenho e confiabilidade. Em vez de baixar a CRL em cada conexão pelo navegador cliente para OCSP, o Microsoft Entra ID baixa uma vez na primeira entrada e a armazena em cache, melhorando assim o desempenho e a confiabilidade da verificação da CRL. Também indexamos o cache para que a pesquisa seja sempre muito mais rápida. Os clientes devem publicar CRLs para revogação de certificado.

As etapas a seguir são um fluxo típico da verificação de CRL:

  1. O Microsoft Entra ID tenta baixar a CRL no primeiro evento de entrada de qualquer usuário com um certificado do emissor ou autoridade de certificação confiável correspondente.
  2. O Microsoft Entra ID armazena em cache e reutiliza a CRL para qualquer uso subsequente. Ele honra a próxima data de atualização e, se disponível, a próxima data de publicação da CRL (usada pelas autoridades de certificação do Windows Server) no documento da CRL.
  3. A autenticação baseada em certificado de usuário falhará se:

    • Uma CRL foi configurada para o emissor confiável e o Microsoft Entra ID não pode baixar a CRL, devido a restrições de disponibilidade, tamanho ou latência.

    • O certificado do usuário é listado como revogado na CRL.

      Captura de tela do certificado de usuário revogado na CRL.

    • O Microsoft Entra ID tenta baixar uma nova CRL do ponto de distribuição se o documento CRL armazenado em cache tiver expirado.

Nota

O Microsoft Entra ID verifica a CRL da autoridade de certificação emissora e outras autoridades de certificação na cadeia de confiança PKI até a autoridade de certificação raiz. Temos um limite de até 10 CAs do certificado de cliente folha para validação de CRL na cadeia PKI. A limitação é garantir que um agente mal-intencionado não derrube o serviço carregando uma cadeia PKI com um grande número de CAs com um tamanho de CRL maior. Se a cadeia PKI do locatário tiver mais de 5 CAs e em caso de comprometimento da CA, os Administradores de Política de Autenticação deverão remover o emissor confiável comprometido da configuração do locatário do Microsoft Entra.

Importante

Devido à natureza dos ciclos de cache e publicação de CRL, é altamente recomendado, no caso de uma revogação de certificado, também revogar todas as sessões do usuário afetado no Microsoft Entra ID.

A partir de agora, não há como forçar ou reativar manualmente o download da CRL.

Como configurar a revogação

Para revogar um certificado de cliente, o Microsoft Entra ID busca a lista de revogação de certificados (CRL) das URLs carregadas como parte das informações da autoridade de certificação e a armazena em cache. O último carimbo de data/hora de publicação (propriedade Data Efetiva) na CRL é usado para garantir que a CRL ainda seja válida. A CRL é referenciada periodicamente para revogar o acesso aos certificados que fazem parte da lista.

Se for necessária uma revogação mais instantânea (por exemplo, se um usuário perder um dispositivo), o token de autorização do usuário pode ser invalidado. Para invalidar o token de autorização, defina o campo StsRefreshTokenValidFrom para esse usuário específico usando o Windows PowerShell. Você deve atualizar o campo StsRefreshTokenValidFrom para cada usuário para o qual deseja revogar o acesso.

Para garantir que a revogação persista, você deve definir a Data efetiva da CRL para uma data após o valor definido por StsRefreshTokenValidFrom e garantir que o certificado em questão esteja na CRL.

Nota

Os módulos Azure AD e MSOnline PowerShell foram preteridos a partir de 30 de março de 2024. Para saber mais, leia a atualização de descontinuação. Após essa data, o suporte para esses módulos é limitado à assistência de migração para o SDK do Microsoft Graph PowerShell e correções de segurança. Os módulos preteridos continuarão a funcionar até 30 de março de 2025.

Recomendamos migrar para o Microsoft Graph PowerShell para interagir com o Microsoft Entra ID (anteriormente Azure AD). Para perguntas comuns sobre migração, consulte as Perguntas frequentes sobre migração. Nota: As versões 1.0.x do MSOnline podem sofrer interrupções após 30 de junho de 2024.

As etapas a seguir descrevem o processo de atualização e invalidação do token de autorização definindo o campo StsRefreshTokenValidFrom .

  1. Conecte-se ao PowerShell:

    Connect-MgGraph

  2. Recupere o valor StsRefreshTokensValidFrom atual para um usuário:

            $user = Get-MsolUser -UserPrincipalName test@yourdomain.com`
        $user.StsRefreshTokensValidFrom

  3. Configure um novo valor StsRefreshTokensValidFrom para o usuário igual ao carimbo de data/hora atual:

            Set-MsolUser -UserPrincipalName test@yourdomain.com -StsRefreshTokensValidFrom ("03/05/2021")

A data que você definiu deve ser no futuro. Se a data não estiver no futuro, a propriedade StsRefreshTokensValidFrom não será definida. Se a data estiver no futuro, StsRefreshTokensValidFrom será definido para a hora atual (não a data indicada pelo comando Set-MsolUser).

Noções básicas sobre validação de CRL (Visualização)

Uma CRL é um registro de certificados digitais que foram revogados antes do final de seu período de validade por uma autoridade de certificação (CA). Quando as autoridades de certificação são carregadas no repositório confiável do Microsoft Entra, uma CRL ou, mais especificamente, o atributo CrlDistributionPoint, não é necessária. Uma autoridade de certificação pode ser carregada sem um ponto de extremidade de CRL e a autenticação baseada em certificado não falhará se uma autoridade de certificação emissora não tiver uma CRL especificada.

Para fortalecer a segurança e evitar configurações incorretas, um Administrador de Política de Autenticação pode exigir que a autenticação CBA falhe se nenhuma CRL estiver configurada para uma autoridade de certificação que emite um certificado de usuário final.

Ativar validação de CRL

Para habilitar a validação de CRL, clique em Exigir validação de CRL (recomendado).

Captura de tela de como exigir a validação de CRL.

Uma vez habilitado, qualquer CBA falhará se o certificado de usuário final tiver sido emitido por uma autoridade de certificação sem CRL configurada.

Um administrador de política de autenticação pode isentar uma autoridade de certificação se sua CRL tiver problemas que devem ser corrigidos. Clique em Adicionar isenção e selecione as autoridades de certificação que devem ser isentas.

Captura de tela de como isentar CAs da validação de CRL.

As autoridades de certificação na lista de isentos não precisam ter a CRL configurada e os certificados de usuário final que emitem não falham na autenticação.

Nota

Há um problema conhecido com o seletor de objetos em que os itens selecionados não são exibidos corretamente. Use a guia Autoridades de certificação para selecionar ou remover autoridades de certificação.

Captura de tela de autoridades de certificação isentas da validação de CRL.

Como o CBA funciona com uma política de força de autenticação de Acesso Condicional

Os clientes podem criar uma política de força de autenticação de Acesso Condicional para especificar que o CBA seja usado para acessar um recurso.

Você pode usar a força de autenticação MFA resistente a phishing integrada. Essa política só permite métodos de autenticação resistentes a phishing, como CBA, chaves de segurança FIDO2 e Windows Hello for Business.

Você também pode criar uma força de autenticação personalizada para permitir que apenas o CBA acesse recursos confidenciais. Você pode permitir o CBA como um fator único, multifator ou ambos. Para obter mais informações, consulte Força da autenticação de acesso condicional.

Força de autenticação CBA com opções avançadas

Na política de métodos de autenticação CBA, um administrador de política de autenticação pode determinar a força do certificado usando a política de vinculação de autenticação no método CBA. Agora você pode configurar as opções avançadas ao criar uma força de autenticação personalizada para exigir que um certificado específico seja usado, com base em OIDs de emissor e política, quando os usuários executam CBA para acessar determinados recursos confidenciais. Esse recurso fornece uma configuração mais precisa para determinar os certificados e usuários que podem acessar recursos. Para obter mais informações, consulte Opções avançadas para a força da autenticação de Acesso Condicional.

Noções básicas sobre logs de entrada

Os logs de entrada fornecem informações sobre entradas e como seus recursos são usados por seus usuários. Para obter mais informações sobre logs de entrada, consulte Logs de entrada no Microsoft Entra ID.

Vamos percorrer dois cenários, um em que o certificado satisfaz a autenticação de fator único e outro em que o certificado satisfaz a MFA.

Para os cenários de teste, escolha um usuário com uma política de Acesso Condicional que exija MFA. Configure a política de vinculação do usuário mapeando o SAN Principal Name para UserPrincipalName.

O certificado de usuário deve ser configurado como esta captura de tela:

Captura de ecrã do certificado do utilizador.

Resolução de problemas de início de sessão com variáveis dinâmicas em registos de início de sessão

Embora os logs de entrada forneçam todas as informações para depurar os problemas de entrada de um usuário, há momentos em que valores específicos são necessários e, como os logs de entrada não suportam variáveis dinâmicas, os logs de entrada teriam informações ausentes. Por exemplo: O motivo da falha no log de entrada mostraria algo como "A CRL (Lista de Revogação de Certificados) falhou na validação da assinatura. O Identificador de Chave de Assunto Esperado {expectedSKI} não corresponde à Chave de Autoridade CRL {crlAK}. Solicite ao administrador do locatário que verifique a configuração da CRL." onde {expectedSKI} e {crlAKI} não são preenchidos com valores corretos.

Quando o login dos usuários com o CBA falhar, copie os detalhes do log do link 'Mais detalhes' na página de erro. Para obter informações mais detalhadas, consulte a página de erro do CBA

Testar a autenticação de fator único

Para o primeiro cenário de teste, configure a política de autenticação em que a regra de assunto do Emissor satisfaça a autenticação de fator único.

Captura de tela da configuração da política de Autenticação mostrando a autenticação de fator único necessária.

  1. Entre no centro de administração do Microsoft Entra como o usuário de teste usando o CBA. A política de autenticação é definida onde a regra de assunto do emissor satisfaz a autenticação de fator único.

  2. Procure e selecione Logs de login.

    Vamos ver mais de perto algumas das entradas que você pode encontrar nos logs de login.

    A primeira entrada solicita o certificado X.509 do usuário. O status Interrompido significa que a ID do Microsoft Entra validou que o CBA está habilitado no locatário e um certificado é solicitado para autenticação.

    Captura de ecrã da entrada de autenticação de fator único nos registos de início de sessão.

    Os Detalhes da atividade mostram que isso é apenas parte do fluxo de login esperado onde o usuário seleciona um certificado.

    Captura de ecrã dos detalhes da atividade nos registos de início de sessão.

    Os Detalhes Adicionais mostram as informações do certificado.

    Captura de ecrã de detalhes adicionais multifatores nos registos de início de sessão.

    Essas entradas adicionais mostram que a autenticação foi concluída, um token de atualização primário é enviado de volta ao navegador e o usuário tem acesso ao recurso.

    Captura de ecrã da entrada do token de atualização nos registos de início de sessão.

Testar autenticação multifator

Para o próximo cenário de teste, configure a política de autenticação em que a regra policyOID satisfaça a autenticação multifator.

Captura de tela da configuração da política de Autenticação mostrando a autenticação multifator necessária.

  1. Entre no centro de administração do Microsoft Entra usando o CBA. Como a política foi definida para satisfazer a autenticação multifator, a entrada do usuário é bem-sucedida sem um segundo fator.

  2. Procure e selecione Logins.

    Você verá várias entradas nos logs de entrada, incluindo uma entrada com status Interrompido .

    Captura de ecrã de várias entradas nos registos de início de sessão.

    Os Detalhes da atividade mostram que isso é apenas parte do fluxo de login esperado onde o usuário seleciona um certificado.

    Captura de ecrã dos detalhes de início de sessão de segundo fator nos registos de início de sessão.

    A entrada com status Interrompido tem mais informações de diagnóstico na guia Detalhes Adicionais .

    Captura de ecrã dos detalhes da tentativa interrompida nos registos de início de sessão.

    A tabela a seguir tem uma descrição de cada campo.

    Campo Descrição
    Nome da entidade do certificado de usuário Refere-se ao campo de nome do assunto no certificado.
    Vinculação de certificado de usuário Certificado: Nome principal; Atributo do usuário: userPrincipalName; Classificação: 1
    Isso mostra qual campo de certificado SAN PrincipalName foi mapeado para o atributo de usuário userPrincipalName e foi prioridade 1.
    Nível de autenticação de certificado de usuário multiFactorAuthentication
    Tipo de nível de autenticação de certificado de usuário PolicyId
    Isso mostra que o OID da política foi usado para determinar a força da autenticação.
    Identificador de nível de autenticação de certificado de usuário 1.2.3.4
    Isso mostra o valor da política de identificador OID do certificado.

Noções básicas sobre a página de erro de autenticação baseada em certificado

A autenticação baseada em certificado pode falhar por motivos como o certificado ser inválido, ou o usuário selecionar o certificado errado ou um certificado expirado, ou devido a um problema de CRL (Lista de Revogação de Certificados). Quando a validação do certificado falha, o usuário vê este erro:

Captura de ecrã de um erro de validação de certificado.

Se o CBA falhar em um navegador, mesmo que a falha seja porque você cancela o seletor de certificados, você precisará fechar a sessão do navegador e abrir uma nova sessão para tentar o CBA novamente. Uma nova sessão é necessária porque os navegadores armazenam o certificado em cache. Quando o CBA é repetido, o navegador envia o certificado armazenado em cache durante o desafio TLS, o que causa falha de entrada e erro de validação.

Selecione Mais detalhes para obter informações de log que podem ser enviadas a um Administrador de Política de Autenticação, que, por sua vez, pode obter mais informações dos logs de entrada.

Captura de ecrã dos detalhes do erro.

Selecione Outras maneiras de entrar para tentar outros métodos disponíveis para o usuário entrar.

Nota

Se você repetir o CBA em um navegador, ele continuará falhando devido ao problema de cache do navegador. Os usuários precisam abrir uma nova sessão do navegador e entrar novamente.

Captura de ecrã de uma nova tentativa de início de sessão.

Autenticação baseada em certificado nos métodos MostRecentlyUsed (MRU)

Depois que um usuário se autentica com êxito usando o CBA, o método de autenticação MostRecentlyUsed (MRU) do usuário é definido como CBA. Da próxima vez, quando o usuário insere seu UPN e seleciona Next, o usuário é levado diretamente para o método CBA e não precisa selecionar Usar o certificado ou cartão inteligente.

Para redefinir o método MRU, o usuário precisa cancelar o seletor de certificados, selecionar Outras maneiras de entrar, selecionar outro método disponível para o usuário e autenticar com êxito.

Suporte de identidade externa

Um usuário convidado B2B de identidade externa pode usar o CBA no locatário doméstico e, se as configurações entre locatários para o locatário de recursos estiverem configuradas para confiar no MFA do locatário doméstico, a autenticação CBA do usuário no locatário doméstico será honrada. Para obter mais informações sobre como habilitar a autenticação multifator Confiar de locatários do Microsoft Entra, consulte Configurar o acesso entre locatários de colaboração B2B. O CBA no locatário de recursos ainda não é suportado.

Próximos passos