Aprofundamento técnico de autenticação com base em certificado do Microsoft Entra

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.

Seguem-se os passos a dar:

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.

   

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 utilizador não vir o link de início de sessão, verifique se o CBA está habilitado no tenant. 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, apenas os utilizadores no âmbito do CBA podem autenticar-se com sucesso numa aplicação que utiliza o Microsoft Entra ID como o seu fornecedor de identidade (IdP).

   

   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.

   

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 certauth é 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 esta solicitação aparece no registo 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 *.certauth.login.microsoftonline.com 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 pistas do emissor. Não codifique a URL com o tenantId porque pode mudar para utilizadores 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 ambiente do 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 habilitar as sugestões de emissor.

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

   

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 Microsoft Entra ID identifica o utilizador usando a associação de nome de utilizador configurada no tenant para mapear o valor do campo do certificado para o valor do atributo do utilizador.

8. Se for encontrado um utilizador único com uma política de Acesso Condicional que exija autenticação multifator e a regra de vinculação de autenticação de certificado satisfazer a MFA, o ID do Microsoft Entra autenticará o utilizador imediatamente. Se a autenticação multifator (MFA) for necessária, mas o certificado satisfizer apenas um fator, será oferecida a autenticação sem senha ou FIDO2 como um segundo fator, se os utilizadores já estiverem registados.

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 indicações do emissor enviam de volta uma Indicação de CA Confiável como parte do handshake do 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 de confiança.

Ativar sugestões do emissor

Para ativar, marque na caixa de seleção Dicas do emissor. Política de autenticação Os administradores devem selecionar Eu reconheço depois de certificar-se de que o proxy com a inspeção TLS habilitada está atualizado corretamente e salvar.

Nota

Se a sua organização tiver firewalls ou proxies com inspeção TLS, tenha em atenção que desativou a inspeção TLS do endpoint certauth capaz de coincidir com qualquer nome sob [*.]certauth.login.microsoftonline.com, personalizado de acordo com o proxy específico em uso.

Nota

A URL da autoridade de certificação está no formato t{tenantId}.certauth.login.microsoftonline.com depois de as sugestões do emissor serem ativadas.

Propagação de atualização do repositório de confiança da autoridade certificadora

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 utilizadores não podem autenticar-se com certificados emitidos pelas novas autoridades de certificação até que as indicações 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 utilizadores veem a seguinte mensagem de erro quando as atualizações do repositório de confiança da autoridade de certificação estão em propagação.

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

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

1. CBA (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 em iOS tem problemas conhecidos e está bloqueado em 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 utilizador é considerado habilitado para MFA quando está incluído nas definiçõ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 precisa de outro fator para completar o MFA e é por isso que não permitiremos o registro de outros métodos sem satisfazer o MFA. Se o utilizador não tiver nenhum outro método de autenticação MFA registado e for adicionado ao âmbito do método de autenticação CBA, o utilizador não poderá confirmar o registo de outros métodos de autenticação nem obter MFA.

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 (OR)
2. O Administrador da Política de Autenticação pode emitir um Passe de Acesso Temporário (OR)
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. O Administrador da Política de Autenticação pode emitir um Passe de Acesso Temporário (OR)
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. O Administrador da Política de Autenticação pode emitir um Passe de Acesso Temporário (OR)
2. O usuário precisa registrar outro método MFA (quando o usuário pode usar o certificado MF em algum dispositivo) (OR)
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.

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 antiga 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 Entra ID>Multifactor authentication>Configurações adicionais de autenticação multifator baseadas em nuvem.

   

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

   

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.

   

2. Selecione Entrar 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.

   

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

   

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 utilizador vê disponíveis segundos fatores de autenticação, que neste caso é a autenticação sem palavra-passe. Selecione Aprovar uma solicitação no meu aplicativo Microsoft Authenticator.

   

5. Você receberá uma notificação no seu telefone. Selecione Aprovar login?.

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

   

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 vinculação de autenticação ajuda a determinar a força da autenticação como de um 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 de OID de emissor e política têm precedência sobre as regras de OID de política. As regras da política OID têm primazia sobre as regras do emissor do certificado.
2. As regras de OID do emissor e 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 que satisfaça o valor do emissor e o OID da política receberá 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. A Policy OID tem uma prioridade de vinculação de autenticação forte mais alta do que a do 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íticas 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, o que afeta alguns cenários de registo de dispositivos, incluindo:

• Inscrição no Windows Hello para Empresas
• Registo da Chave de Segurança Fido2
• Inicio de Sessão no Windows Sem Senha via Telefone

O registo de dispositivos com o Workplace Join, ID do Microsoft Entra e os cenários de ingresso de dispositivos híbridos do Microsoft Entra não são afetados. As regras da política de autenticação CBA que usam 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 da política de autenticação que atualmente usa tanto o emissor como o OID 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 vinculaçõ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	Tipo
NomePrincipal	X509:<PN>bob@woodgrove.com	Nome Principal do Utilizador onPremisesUserPrincipalName IdsDeUtilizadoresDeCertificado	baixa afinidade
RFC822Nome	X509:<RFC822>user@woodgrove.com	Nome Principal do Utilizador onPremisesUserPrincipalName IdsDeUtilizadoresDeCertificado	baixa afinidade
EmissorAndSubject	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	IdsDeUtilizadoresDeCertificado	baixa afinidade
Assunto	X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	IdsDeUtilizadoresDeCertificado	baixa afinidade
ESQUI	X509:<SKI>aB1cD2eF3gH4iJ5kL6-mN7oP8qR=	IdsDeUtilizadoresDeCertificado	alta afinidade
SHA1Chave Pública	X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR O valor SHA1PublicKey (hash SHA1 de todo o conteúdo do certificado, incluindo a chave pública) é encontrado na propriedade Thumbprint do certificado.	IdsDeUtilizadoresDeCertificado	alta afinidade
EmissorESerialNumber	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	IdsDeUtilizadoresDeCertificado	alta afinidade

Importante

Você pode usar o módulo PowerShell CertificateBasedAuthentication para localizar os valores CertificateUserIds corretos para um usuário a partir do certificado de usuário final.

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

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 inquilino, criando regras personalizadas com base no Emissor e no OID de Política, ou no OID de Política, ou no 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 Graph retorna o atributo de prioridade para cada ligação e são utilizados 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 do vínculo configurado estiver no certificado apresentado, a ID do Microsoft Entra irá corresponder o valor no campo de certificado ao valor do atributo de objeto do utilizador.
   1. Se for encontrada uma correspondência, a autenticação do utilizador 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 apenas 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 utilizador pode apresentar qualquer certificado no início de sessão e, desde que a Associação de Nome de Utilizador CBA esteja definida para apontar para o campo certificateUserIds para procurar o tipo de associação específico (ou seja, Emissor+SerialNumber neste exemplo), então o utilizador consegue iniciar sessão com sucesso.

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 a entrada 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 é recomendável não permitir um certificado para várias contas de usuário do Microsoft Entra.

Contas apenas 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 usará o certificado. Cada conta é 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 a utilizar ligações de alta afinidade (ou seja, autenticação forte), as ligações podem ser, por exemplo, Emissor + Número de Série e SKI, podendo ter a seguinte aparência:

Ligações de nome de usuário:

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

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 dos usuários apresenta o mesmo certificado no início de sessão, o utilizador inicia sessão com êxito porque a sua conta corresponde a um valor exclusivo nesse certificado. Uma conta é 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 híbridas sincronizadas Para contas sincronizadas, a abordagem é diferente. Embora os Administradores de Política de Autenticação possam mapear valores exclusivos para cada conta de usuário que usa o certificado, a prática comum de preencher todos os valores para cada conta no Microsoft Entra ID dificulta isso. Em vez disso, o Microsoft Entra Connect deve filtrar os valores desejados por cada conta para valores exclusivos inseridos na conta no Microsoft Entra ID. 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 que contribuem com utilizadores num único inquilino do Microsoft Entra. Nesse caso, o Microsoft Entra Connect aplica 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 informe à 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 AD, configure uma nova regra de entrada personalizada com alta precedência (número inferior a 100). Adicione uma transformação Expression com o campo altSecurityIdentities como origem. A expressão de destino usa 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 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", então filtramos para o valor SHA1PublicKey de altSecurityIdentities. Se o valor for desenvolvedor, então filtramos 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 obtém todos os valores e sincroniza com o Microsoft Entra ID – não apenas o primeiro que encontra.

1. Um segundo exemplo que mostra como enviar por push um valor vazio se o atributo de controle estiver vazio é:

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 control, 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 associações de nome de utilizador a apontar 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 impostos pelo serviço (45 MB no Microsoft Entra ID público 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, Microsoft Entra ID baixa apenas uma vez no primeiro início de sessão e armazena em cache. Essa ação melhora o desempenho e a confiabilidade da verificação de 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 respeita 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 de CRL.
3. A autenticação baseada em certificado de usuário falhará se:

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

   • O certificado do usuário é listado como 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 faz a verificação do CRL da autoridade de certificação emissora e de outras autoridades de certificação na cadeia de confiança da 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 comprometa o serviço ao carregar uma cadeia PKI com um grande número de CAs e um CRL de maior dimensão. Se a cadeia PKI do locatário tiver mais de 5 CAs e se houver um 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 do cache de CRL e dos ciclos de publicação, é altamente recomendável que, se houver uma revogação de certificado, também se revoguem todas as sessões do utilizador 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 timestamp de publicação (propriedade Data Efetiva) na CRL é utilizado para garantir que a CRL ainda seja válida. A Lista de Revogação de Certificados (CRL) é consultada regularmente para revogar os 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 StsRefreshTokensValidFrom para esse usuário específico usando o Windows PowerShell. Você deve atualizar o campo StsRefreshTokensValidFrom 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 StsRefreshTokensValidFrom e garantir que o certificado em questão esteja na CRL.

As etapas a seguir descrevem o processo para atualizar e invalidar o token de autorização definindo o campo StsRefreshTokensValidFrom .

# Authenticate to Microsoft Graph
Connect-MgGraph -Scopes "User.Read.All"

# Get the user
$user = Get-MgUser -UserPrincipalName "test@yourdomain.com"

# Get the StsRefreshTokensValidFrom property
$user.StsRefreshTokensValidFrom

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 a validação de CRL

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 inseridas no repositório confiável do Microsoft Entra, uma CRL, ou mais especificamente, o atributo CrlDistributionPoint, não é necessário. Uma autoridade de certificação pode ser carregada sem um ponto de acesso CRL, e a autenticação baseada em certificados não falhará se a 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, selecione Exigir validação de CRL (recomendado).

Uma vez habilitada, qualquer falha de CBA ocorre porque o certificado de usuário final foi 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. Selecione Adicionar isenção e selecione as autoridades de certificação que devem ser isentas.

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.

Selecione CAs e selecione Adicionar. A caixa de texto Pesquisar pode ser usada para filtrar listas de autoridades de certificação e assim selecionar CAs específicas.

Definição do Escopo da Autoridade de Certificação (CA) (Pré-visualização)

O escopo da autoridade de certificação (CA) no Microsoft Entra permite que os administradores de locatários restrinjam o uso de autoridades de certificação (CAs) específicas a grupos de usuários definidos. Esse recurso aumenta a segurança e a capacidade de gerenciamento da autenticação baseada em certificado (CBA), garantindo que apenas usuários autorizados possam se autenticar usando certificados emitidos por CAs específicas.

A limitação da autoridade de certificação é particularmente útil em cenários multi-PKI ou B2B em que várias autoridades de certificação são usadas em diferentes populações de usuários. Ele ajuda a evitar o acesso não intencional e suporta a conformidade com as políticas organizacionais.

principais benefícios

• Restringir o uso do certificado a grupos de usuários específicos
• Suporte para ambientes PKI complexos com várias autoridades de certificação
• Proteção reforçada contra uso indevido ou comprometimento de certificados
• Visibilidade do uso da autoridade de certificação por meio de logs de login e ferramentas de monitoramento

O escopo da autoridade de certificação permite que os administradores definam regras que associem uma autoridade de certificação (identificada por seu identificador de chave de assunto ou SKI) a um grupo específico do Microsoft Entra. Quando um usuário tenta se autenticar usando um certificado, o sistema verifica se a autoridade de certificação emissora do certificado tem escopo para um grupo que inclui o usuário. O Entra percorre a cadeia de CA e aplica todas as regras de escopo até que o usuário seja encontrado em um dos grupos em todas as regras de escopo. Se o usuário não estiver no grupo com escopo, a autenticação falhará, mesmo que o certificado seja válido.

Etapas para habilitar a funcionalidade de escopo da CA

1. Entre no centro de administração do Microsoft Entra como pelo menos um Administrador de Política de Autenticação.
2. Navegue até Entra ID>Métodos de autenticação>Autenticação baseada em certificado.
3. Em Configurar, vá para Política de escopo do emissor de certificados

1. Selecione Adicionar regra

1. Selecione Filtrar CAs por PKI. As CAs clássicas mostrarão todas as CAs do armazenamento clássico e ao selecionar uma PKI específica, mostrarão todas as CAs da PKI selecionada. Selecione uma PKI.

1. O menu suspenso do emissor do certificado mostrará todas as autoridades de certificação da PKI selecionada. Selecione uma autoridade de certificação para criar uma regra de escopo.

1. Selecione Adicionar grupo

1. Selecione um grupo

1. Selecione Adicionar para salvar a regra

1. Selecione Eu reconheço e selecione Salvar para salvar a configuração do CBA

1. Para editar ou excluir uma política de escopo da autoridade de certificação, selecione "..." na linha da regra. Selecione Editar para editar a regra e Excluir para excluir a regra.

Limitações conhecidas

• Apenas um grupo pode ser atribuído por autoridade certificadora.
• O sistema suporta um máximo de 30 regras de escopo.
• O escopo é aplicado no nível intermediário da autoridade de certificação.
• A configuração incorreta pode resultar em bloqueios de usuário se não existirem regras de escopo válidas.

Entradas de registo de início de sessão

• O registo de login indicará o sucesso e, na guia Detalhes Adicionais, o SKI da autoridade de certificação da política de escopo será mostrado.

• Quando uma autenticação CBA falha devido a uma regra de escopo da CA, a aba Informações Básicas no registo de início de sessão mostrará o código de erro 500189

• Os usuários finais verão a mensagem de erro abaixo.

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 nível de autenticação no Acesso Condicional para especificar que a autenticação baseada em certificado (CBA) é utilizada para aceder a um recurso.

Você pode usar a autenticidade MFA integrada e resistente ao phishing. 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.

Compreensão dos 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 registos de início de sessão, consulte Registos de início de sessão 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:

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 estão preenchidos com os valores corretos.

Quando a autenticação dos utilizadores com o CBA falhar, copie os detalhes do registo a partir do link 'Mais detalhes' na página de erro. Para informações mais detalhadas, veja Entender a página de erros 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.

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 estado Interrompido significa que a ID do Microsoft Entra validou que o CBA está ativado no inquilino e um certificado é requisitado para a autenticação.

   

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

   

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

   

   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.

   

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.

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ários registos nos registos de início de sessão, incluindo um registo com o status Interrompido.

   

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

   

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

   

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

   Campo	Descrição
   Nome do titular do certificado de utilizador	Refere-se ao campo de nome do sujeito 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	Autenticação Multifatorial
   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 robustez 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:

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.

Nota

No entanto, o navegador Edge adicionou um novo recurso para redefinir a seleção de certificados sem reiniciar o navegador.

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.

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

Redefinir a escolha de certificado no Microsoft Edge

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, pois os navegadores armazenam o certificado em cache. No entanto, o navegador Edge adicionou um novo aprimoramento para redefinir a opção de certificado no navegador.

• Quando o CBA falhar, o usuário será enviado para a página de erro

• Selecione o ícone de cadeado à esquerda do URL do endereço e selecione Suas opções de certificado.

• Selecione Redefinir opções de certificado

• Selecione Redefinir opções na caixa de diálogo

• Clique em Outras maneiras de entrar na página de erro

• Selecione Usar um certificado ou cartão inteligente no seletor e continue com a autenticação CBA.

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.

O método de autenticação MRU é definido no nível do usuário, portanto, se um usuário entrar com êxito em um dispositivo diferente usando um método de autenticação diferente, o MRU será redefinido no usuário para o método conectado no momento.

Suporte de identidade externa

Um utilizador convidado B2B de identidade externa pode usar o CBA no locatário de origem e, se as definições entre locatários para o locatário de recursos estiverem configuradas para confiar no MFA do locatário de origem, a autenticação CBA do utilizador no locatário de origem será reconhecida. Para mais informações sobre como habilitar a autenticação multifator Trust 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 tem suporte.

Próximos passos

• Visão geral do Microsoft Entra CBA
• Como configurar o Microsoft Entra CBA
• Microsoft Entra CBA em dispositivos iOS
• Microsoft Entra CBA em dispositivos Android
• Início de sessão com cartão inteligente no Windows usando o Microsoft Entra CBA
• Identificadores de utilizador do certificado
• Como migrar usuários federados
• Perguntas Frequentes
• Solucionar problemas do Microsoft Entra CBA