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

  • Artigo

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

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 em que a CBA do Microsoft Entra está habilitada.

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

Agora vamos explorar cada etapa:

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

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

  3. O usuário insere o nome de usuário na página de entrada do Microsoft Entra e seleciona Avançar. O Microsoft Entra ID faz a descoberta de realm inicial usando o nome de locatário e o nome de usuário é usado para pesquisar o usuário no locatário.

    Captura de tela do portal Entrar no MyApps.

  4. O Microsoft Entra ID verifica se a CBA está habilitada para o locatário. Se a CBA estiver habilitada, 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 a CBA está habilitada no locatário. Para obter mais informações, confira Como habilitar a CBA do Microsoft Entra?.

    Observação

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

    Captura de tela do uso de um certificado ou cartão inteligente.

    Se você habilitou outros métodos de autenticação, como a Entrada por telefone ou as Chaves de segurança, os usuários podem ver uma tela de entrada diferente.

    Captura de tela da entrada se o FIDO2 também estiver habilitado.

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

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

    Observação

    O administrador de rede deve permitir o acesso à página de entrada do usuário e ao ponto de extremidade *.certauth.login.microsoftonline.com para o ambiente de nuvem do cliente. Desabilite a inspeção de TLS no ponto de extremidade de certauth para verificar se a solicitação de certificado do cliente é bem-sucedida como parte do handshake TLS.

    Verifique se a desabilitação da inspeção do TLS também funciona para a nova URL com dicas do emissor. Não embuta em código a URL com tenantId porque ela pode ser alterada para usuários B2B. Use uma expressão regular para permitir que a URL antiga e a nova funcionem para a desabilitação da inspeção do TLS. Por exemplo, dependendo do proxy, use *.certauth.login.microsoftonline.com ou *certauth.login.microsoftonline.com. No Azure Governamental, 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 o próximo recurso de dicas de AC Confiável.

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

    Observação

    Não há suporte para as dicas da AC confiável. Portanto, a lista de certificados não pode ter escopo adicional. Estamos estudando a inclusão dessa funcionalidade no futuro.

    Captura de tela do seletor de certificado.

  7. O Microsoft Entra ID verificará a lista de certificados revogados para se assegurar de que o certificado não foi revogado e é válido. O Microsoft Entra ID identificará 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 único for encontrado com uma política de acesso condicional que requer MFA (autenticação multifator) e a regra de associação de autenticação de certificados atender à MFA, o Microsoft Entra ID conectará o usuário imediatamente. Se houver a necessidade da MFA, mas o certificado atender apenas a um único fator, a entrada sem senha ou o FIDO2 serão oferecidos como um segundo fator, se eles já estiverem registrados.

  9. O Microsoft Entra ID concluirá o processo de entrada enviando um token de atualização principal de volta para indicar uma entrada bem-sucedida.

  10. Se a entrada do usuário for bem-sucedida, ele será capaz de acessar o aplicativo.

A autenticação baseada em certificado é compatível com MFA

A CBA do Microsoft Entra pode realizar a autenticação multifator (MFA). A CBA do Microsoft Entra também pode ser de SF (Fator único) ou de MF (multifator) dependendo da configuração de locatário. Habilitar a CBA faz com que um usuário seja potencialmente capaz de concluir a MFA. Um usuário pode precisar realizar configurações adicionais para obter a MFA e de mais provas para registrar outros métodos de autenticação quando o usuário estiver no escopo da CBA.

Se o usuário habilitado para CBA tiver apenas um certificado SF e precisar concluir a MFA:

  1. Use uma senha e um certificado de SF.
  2. Emitir uma senha de acesso temporária.
  3. O administrador de política de autenticação adiciona um número de telefone e permite a autenticação de mensagem de voz/texto para a conta de usuário.

Se o usuário habilitado para CBA ainda não tiver emitido um certificado e precisar concluir a MFA:

  1. Emitir uma senha de acesso temporária.
  2. O administrador de política de autenticação adiciona um número de telefone e permite a autenticação de mensagem de voz/texto para a conta de usuário.

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

  1. Emitir uma senha de acesso temporária.
  2. O usuário precisa registrar outro método de MFA (quando o usuário puder usar o certificado MF).
  3. Usar senha e certificado MF (quando o usuário puder usar o certificado MF).
  4. O administrador de política de autenticação adiciona um número de telefone e permite a autenticação de mensagem de voz/texto para a conta de usuário.

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

A CBA do Microsoft Entra pode ser usada como um segundo fator para atender aos requisitos de MFA com certificados de fator único. Algumas das combinações com suporte são:

  1. CBA (primeiro fator) e entrada por telefone sem senha (entrada sem senha como segundo fator)
  2. CBA (primeiro fator) e chaves de segurança FIDO2 (segundo fator)
  3. Senha (primeiro fator) e CBA (segundo fator)

Os usuários precisam ter outra maneira de obter a MFA e registrar a entrada sem senha ou o FIDO2 com antecedência para entrar com a CBA do Microsoft Entra.

Importante

Um usuário é considerado capaz de fazer MFA quando está incluído nas configurações do método CBA. Isso significa que um usuário não pode usar a prova como parte da 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, confira Autenticação multifator do Microsoft Entra.

Etapas para configurar a PSI (entrada sem senha com telefone) com a CBA

Para que a entrada sem senha funcione, os usuários devem desabilitar a notificação herdada por meio do aplicativo móvel.

  1. Entre no Centro de administração do Microsoft Entra como, no mínimo, um Administrador de Política de Autenticação.

  2. Siga as etapas em Habilitar a autenticação da entrada sem senha com telefone.

    Importante

    Na configuração anterior, escolha a opção Sem senha. 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 funcionarão.

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

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

  4. Em Opções de verificação, desmarque Notificação em um aplicativo móvel e selecione Salvar.

    Captura de tela de como remover a notificação em um aplicativo móvel.

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

Veja a seguir um exemplo de um usuário que tem certificados de fator único e configurou a entrada sem senha.

  1. Insira seu nome UPN e selecione Avançar.

    Captura de tela de como inserir um nome UPN.

  2. Selecione Entrar com um certificado.

    Captura de tela de como entrar com um certificado.

    Se você habilitou outros métodos de autenticação, como a entrada por telefone ou as chaves de segurança FIDO2, os usuários podem ver uma tela de entrada diferente.

    Captura de tela da maneira alternativa de entrar 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 uma força de autenticação de fator único, o usuário precisa de um segundo fator a fim de atender aos requisitos da MFA. O usuário exibe os segundos fatores disponíveis, que é a entrada sem senha, neste caso. Selecione Aprovar uma solicitação no aplicativo Microsoft Authenticator.

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

  5. Você receberá uma notificação em seu celular. Selecione Aprovar entrada?. Captura de tela da solicitação de aprovação.

  6. Insira o número que você vê na tela do navegador ou do aplicativo no Microsoft Authenticator.

    Captura de tela da correspondência de número.

  7. Selecione Sim e o usuário poderá autenticar e se conectar.

Noções básicas sobre a política de associaçã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. Um administrador pode alterar o valor padrão de fator único para multifator ou definir configurações de política personalizadas usando a entidade do emissor ou campos OID de política ou o emissor e os campos OID de política no certificado.

Pontos fortes do certificado

Um administrador pode determinar se os certificados são multifator ou de fator único. Para obter mais informações, consulte a documentação que mapeia os Níveis de Garantia de Autenticação NIST para os Métodos de Autenticação do Microsoft Entra, que se baseia em NIST 800-63B SP 800-63B, Diretrizes de Identidade Digital: Autenticação e Gerenciamento de Ciclo de Vida.

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 verificar se os certificados estão protegidos com um PIN ou módulo biométrico para serem considerados multifator.

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

Porque várias regras de política de associação de autenticação personalizadas podem ser criadas com campos de certificado diferentes, como usar emissor + OID da política ou apenas OID da 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. Elas são as seguintes:

  1. As regras de OID de política + emissor terão prioridade sobre as regras de OID de política. As regras de OID de política terão prioridade sobre as regras do emissor do certificado.
  2. As regras de OID de política + emissor são avaliadas primeiro. Se você tiver uma regra personalizada com o emissor CA1 e OID de política 1.2.3.4.5 com MFA, somente o certificado A satisfará o valor do emissor e o OID de política receberá MFA.
  3. Em seguida, as regras personalizadas que usam OIDs de política são avaliadas. Se você tiver um certificado A com um OID de política 1.2.3.4.5, uma credencial B derivada com base nesse certificado tiver um OID de política 1.2.3.4.5.6 e a regra personalizada for definida como OID de política com o valor 1.2.3.4.5 com MFA, somente o certificado A atenderá à MFA e a credencial B atenderá apenas à autenticação de fator único. Se o usuário usou a credencial derivada durante a entrada e foi configurado para obter a MFA, será solicitado que ele tenha um segundo fator para que a autenticação seja bem-sucedida.
  4. Se houver um conflito entre vários OIDs de política (como quando um certificado tiver dois OIDs de política, em que um se associa à autenticação de fator único e o outro se associa à MFA), trate o certificado como uma autenticação de fator único.
  5. Em seguida, as regras personalizadas que usam a CA do emissor são avaliadas.
  6. Se um certificado tiver regras do OID e do emissor da política coincidentes, o OID da política sempre será verificado primeiro e, se nenhuma regra de política for encontrada, as associações do emissor serão verificadas. O OID de política tem uma prioridade de associação de autenticação forte mais alta do que o emissor.
  7. Se uma AC se associar à MFA, todos os certificados de usuário emitidos por essa AC se qualificarão como MFA. A mesma lógica se aplica à autenticação de fator único.
  8. Se um OID de política estiver associado à 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) se qualificarão como MFA.
  9. Um emissor de certificado só pode ter uma associação de autenticação forte válida (ou seja, um certificado não pode ser associado a um fator único e à MFA).

Importante

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

  • Inscrição no Windows Hello para Empresas
  • Registro da chave de segurança do Fido2
  • Início de sessão por telefone sem senha no Windows

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

  • Editar as regras de política de autenticação baseada em certificado que usam ao mesmo tempo as opções Emissor e OID de Política e remover o requisito Emissor ou OID e salvar. OR
  • Remover a regra de política de autenticação que está usando o Emissor e o OID de Política e criar regras usando apenas o emissor ou OID da política

Estamos trabalhando para solucionar o problema.

Noções básicas sobre a política de associação de nome de usuário

A política de associação de nome de usuário ajuda a validar o certificado do usuário. Por padrão, o SAN (Nome Alternativo da Entidade) no certificado é mapeado para o atributo UserPrincipalName do objeto de usuário para determinar o usuário.

Obter maior segurança com associações de certificado

Existem sete métodos com suporte para associações de certificado. Em geral, os tipos de mapeamento serão considerados de alta afinidade se forem baseados em identificadores que não podem ser reutilizados como Identificadores de chave da entidade ou Chave pública SHA1. Esses identificadores transmitem uma garantia maior de que apenas um único certificado pode ser usado para autenticar o respectivo usuário.

Os tipos de mapeamento com base em nomes de usuário e endereços de email 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 associações de alta afinidade. Para obter mais informações, consulte certificateUserIds.

Campo de mapeamento de certificado Exemplos de valores em certificateUserIds Atributos de objeto de usuário Type
Nome principal X509:<PN>bob@woodgrove.com userPrincipalName
onPremisesUserPrincipalName
certificateUserIds		 baixa afinidade
RFC822Name X509:<RFC822>user@woodgrove.com userPrincipalName
onPremisesUserPrincipalName
certificateUserIds		 baixa afinidade
IssuerAndSubject (preview) X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest certificateUserIds baixa afinidade
Subject (preview) X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest certificateUserIds baixa afinidade
SKI X509:<SKI>123456789abcdef certificateUserIds alta afinidade
SHA1PublicKey X509:<SHA1-PUKEY>123456789abcdef certificateUserIds alta afinidade
IssuerAndSerialNumber (preview) X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
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 associação de afinidade no nível do locatário e substituir com regras personalizadas (preview)

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

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

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

  1. Pesquise o objeto do usuário usando o nome de usuário ou o nome UPN.
  2. Obtenha a lista de todas as associações de nome de usuário configuradas pelo administrador de locatários 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 "priority" para cada associação e eles serão usados no processo de avaliação.
  3. Se o locatário tiver associação de alta afinidade habilitada ou se o valor do certificado corresponder a uma regra personalizada que exija associação de alta afinidade, remova todas as associações de baixa afinidade da lista.
  4. Avalie cada associação na lista até que uma autenticação bem-sucedida ocorra.
  5. Se o campo do certificado X.509 da associação configurada estiver no certificado apresentado, o Microsoft Entra ID combinará o valor no campo de certificado com o 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 associação de prioridade.
  6. Se o campo de certificado X.509 não estiver no certificado apresentado, passe para a próxima associaçã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 nas associações de nome de usuário configuradas, a autenticação do usuário falhará.

Proteção da configuração do Microsoft Entra ID com várias associações de nome de usuário

Cada atributo de objeto do usuário do Microsoft Entra (userPrincipalName, onPremiseUserPrincipalName, certificateUserIds) disponível para associar certificados a contas de usuário do Microsoft Entra tem 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 associação na diretiva de associação de nome de usuário, o que permite que um administrador acomode um certificado para várias configurações de contas de usuário do Entra.

Importante

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

  • Configure um único método de associação na política de associaçã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 da Política de Autenticação deverá garantir todos os métodos permitidos configurados no mapa da política 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 da Política de Autenticação deverá garantir que ele não tenha mais de uma associação de baixa afinidade.

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

Suporte a vários certificados com uma conta de usuário do 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 se destinar a um smartcard secundário ou dispositivo com capacidade para detentor de credenciais x509, como uma 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 associações de alta afinidade, digamos Emissor + SerialNumber, os valores em CertificateUserIds podem ter a seguinte aparência:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>c11154138u089b48767212a86cd0ef76

Neste exemplo, o primeiro valor representa X509Certificate1 e o segundo valor representa X509Certificate2. O usuário pode apresentar qualquer certificado na entrada e, desde que a Associaçã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 iniciará sessão com êxito.

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

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>c11154138u089b48767212a86cd0ef76

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

Suporte a um certificado com uma conta de usuário do Entra (1:M)

Há cenários em que uma organização precisa que o usuário use o mesmo certificado para se autenticar em múltiplas identidades. Em geral, isso se aplica a contas administrativas. Mas também pode ser aplicado a contas de desenvolvedor ou contas de serviço temporárias. No AD tradicional, o campo altSecurityIdentities é usado para preencher os valores do certificado e uma Dica é usada durante o logon para direcionar o AD para a conta desejada a fim de verificar o logon. 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

Usar a mesma credencial para autenticar em contas de ID do Entra diferentes não é uma configuração muito segura e, por isso, recomenda-se não permitir um mesmo certificado para várias contas de usuário do 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, o administrador de locatários também pode 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 associações de alta afinidade (ou seja, autenticação forte), digamos Emissor + SerialNumber e SKI, isso poderá ter a seguinte aparência:

Associações de nome de usuário:

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

Valores de CertificateUserIds de conta de usuário:
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523

Agora, quando um usuário apresenta o mesmo certificado ao iniciar sessão, ele iniciará a sessão com êxito porque sua conta corresponde a um valor exclusivo nesse certificado. Uma conta será autenticada usando Emissor + SerialNumber e a outra usando a associação SKI.

Observação

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 com suporte será limitado a 3. Se a organização também estiver utilizando associaçõ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 o administrador de locatários possa 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 Entra ID tornaria isso difícil. Em vez disso, o Azure AD Connect deve filtrar os valores desejados por conta para valores exclusivos preenchidos na conta no Entra ID. A regra de exclusividade se aplica dentro do limite de um único diretório/locatário (ou seja, o administrador de locatários também pode 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 Entra ID. Nesse caso, o Azure AD 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 na 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 (por exemplo, detailee, admin, developer, etc.). Selecione um atributo de chave no AD que informará à sincronização qual tipo de conta de usuário o usuário está avaliando (por exemplo, msDS-cloudExtensionAttribute1). Preencha esse atributo com o valor de tipo de usuário desejado, como detailee, admin ou developer. Se essa for a conta principal do usuário, o valor poderá ser deixado vazio/nulo.

O conteúdo deverá ter a seguinte aparência:

Floresta 1 - Account1 (bob@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Floresta 1 - Account2 (bob-admin@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Floresta 2 - ADAccount1 (bob-tdy@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

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

Etapas para sincronizar com certificateUserIds

  1. Configurar o Azure AD 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 ele estiver vazio, então nós o definimos como NULL. Caso contrário, a conta se enquadra no caso padrão e, neste exemplo, filtramos apenas para o mapeamento Issuer+SerialNumber. Se o atributo de chave estiver 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 developer, 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 Entra ID – não apenas o primeiro que encontrar.

  1. Um segundo exemplo que mostra como enviar um valor vazio por push se o atributo de controle estiver vazio é mostrado 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 posteriores que preenchem alternativeSecurityId sejam ignoradas e o resultado fique vazio no 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 a população dos dados no Entra ID.

Verifique se o CBA em cada locatário está configurado com as associaçõ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 na entrada 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 certificado

O processo de revogação de certificado permite que o administrador revogue um certificado emitido anteriormente para que ele não seja usado em uma autenticação futura. A revogação de certificado não revogará os tokens já emitidos do usuário. Siga as etapas para revogar tokens manualmente em Configurar revogação.

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

Um administrador pode 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 do Microsoft Entra a ser baixada com êxito em uma entrada interativa e armazenada em cache é de 20 MB no Entra ID público e 45 MB nas nuvens do governo dos EUA do Azure, 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 certificado que usam aqueles emitidos pela AC correspondente falharão. Como prática recomendada para manter os arquivos CRL dentro dos limites de tamanho, mantenha o tempo de vida do certificado dentro de limites razoáveis e limpe certificados expirados. Para obter mais informações, confira Há um limite para o tamanho da CRL?.

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

"A CRL (Lista de Certificados Revogados) baixada de {uri} excedeu o tamanho máximo permitido de ({size} bytes) para CRLs no Microsoft Entra ID. Tente novamente em alguns minutos. Se o problema persistir, contate os administradores de locatários."

Após o erro, o Microsoft Entra ID tentará baixar a CRL sujeita aos limites do lado do serviço (45 MB no Entra ID público e 150 MB nas nuvens do Governo dos EUA para Azure).

Importante

Se o administrador 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 inicial, mas não deve ser considerado para uso em produção.

A partir de agora, não há suporte para o protocolo OCSP devido a motivos de desempenho e confiabilidade. Em vez de baixar a CRL em cada conexão pelo navegador do cliente para OCSP, o Microsoft Entra ID baixa uma vez na primeira entrada e a armazena em cache, aprimorando, assim, o desempenho e a confiabilidade da verificação de CRL. Também indexaremos o cache para que a pesquisa seja sempre bem mais rápida. Os clientes devem publicar as CRLs para a revogação do certificado.

As seguintes etapas são um fluxo típico da verificação da CRL:

  1. O Microsoft Entra ID tentará baixar a CRL no primeiro evento de entrada de todo usuário com um certificado da autoridade de certificação ou emissor confiável correspondente.
  2. O Microsoft Entra ID armazenará em cache e reutilizará a CRL em todos os usos posteriores. Ele seguirá a Próxima data de atualização e, se disponível, a Próxima data de publicação da CRL (usada por ACs do Windows Server) no documento da CRL.
  3. Haverá falha na autenticação baseada em certificado do usuário se:

    • Uma CRL foi configurada para o emissor confiável e o Microsoft Entra 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 tentar baixar uma nova CRL do ponto de distribuição se o documento da CRL armazenada em cache estiver expirado.

Observação

O Microsoft Entra ID verificar a CRL da AC emissora e outras ACs na cadeia confiável do PKI até a AC raiz. Temos um limite de até 10 ACs do certificado de cliente folha para validação da CRL na cadeia do PKI. A limitação serve para garantir que um ator inapropriado não desative o serviço ao carregar uma cadeia PKI com um grande número de ACs que possuem um tamanho maior de CRL. Se a cadeia PKI do locatário tiver mais de 5 ACs e, em caso de comprometimento da AC, o administrador deve remover o emissor confiável comprometido da configuração de locatário do Microsoft Entra.

Importante

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

Agora não há como forçar ou disparar novamente o download da CRL manualmente.

Como configurar a revogação

Para revogar um certificado do cliente, o Microsoft Entra ID busca a CRL (Lista de Certificados Revogados) nas URLs carregadas como parte das informações da autoridade de certificado e a armazena em cache. O carimbo de data/hora da última publicação (propriedadeEffective Date ) na CRL é usado para garantir que a CRL continua sendo válida. A CRL é referenciada periodicamente para revogar o acesso a certificados que fazem parte da lista.

Se uma revogação mais imediata for necessária (por exemplo, se um usuário perder um dispositivo), o token de autorização do usuário poderá 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 do qual deseja revogar o acesso.

Para garantir que a revogação persista, é preciso definir Effective Date da CRL para uma data posterior ao valor definido por StsRefreshTokenValidFrom e garantir que o certificado em questão esteja na CRL.

Observação

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

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

As etapas a seguir descrevem o processo para atualizar e invalidar o token de autorização pela definição do 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ê define deve estar 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á definida para a hora atual (não a data indicada pelo comando Set-MsolUser).

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

Os clientes podem criar uma política de nível de autenticação de Acesso Condicional para especificar que a CBA seja usada para a obtenção de acesso a um recurso.

É possível usar o nível de autenticação MFA com resistência ao phishing interno. Essa política permite somente métodos de autenticação com resistência ao phishing, como a CBA, as chaves de segurança FIDO2 e o Windows Hello para Empresas.

Além disso, é possível criar um nível de autenticação com personalização para permitir que somente a CBA tenha acesso a recursos confidenciais. Você pode permitir a CBA como uma autenticação de fator único, multifator ou ambos. Para obter mais informações, veja Nível de autenticação de Acesso Condicional.

Nível de autenticação da CBA com opções avançadas

Na política de métodos de autenticação para a CBA, um administrador pode determinar o nível do certificado ao usar a política de associação de autenticação no método de CBA. Agora, é possível configurar as Opções Avançadas ao criar um nível de autenticação com personalização para exigir o uso de um certificado específico, com base nos OIDs do emissor e da política, quando os usuários realizam a CBA para a obtenção de acesso a determinados recursos confidenciais. Este recurso fornece uma configuração mais precisa para determinar os certificados e os usuários que podem ter acesso aos recursos. Para obter mais informações, consulte Opções avançadas para os níveis de autenticação de Acesso Condicional.

Noção básica sobre os logs de entrada

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

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

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

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

Captura de tela do certificado do usuário.

Solução de problemas de logon com variáveis ​​dinâmicas em logs de logon

Embora os logs de logon forneçam todas as informações para a depuração de problemas de logon de um usuário, há momentos em que valores específicos são necessários e, como os logs de logon não oferecem suporte para variáveis dinâmicas, os logs de logon teriam informações ausentes. Por exemplo: o motivo da falha nos logs de logon mostraria algo como “A lista de certificados revogados (CRL) apresentou falha na validação de assinatura. O identificador de chave da entidade esperado {expectedSKI} não corresponde à chave de autoridade da CRL {crlAK}. Faça uma solicitação ao seu administrador de locatários para a verificação da configuração da CRL.”, em que {expectedSKI} e {crlAKI} não são preenchidos com os valores adequados.

Quando o logon dos usuários com a CBA apresentar falha, copie os detalhes dos logs do link “Mais Detalhes” na página de erro. Para obter informações mais detalhadas, consulte Noções básicas sobre a página de erro de autenticação baseada em certificado.

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 entidade do emissor atende à 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 usuário de teste usando o CBA. A política de autenticação é definida onde a regra de entidade do Emissor satisfaz a autenticação de fator único.

  2. Pesquise e selecione Logs de entrada.

    Vamos olhar mais de perto algumas das entradas que você pode encontrar nos Logs de entrada.

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

    Captura de tela da entrada de autenticação de fator único nos logs de entrada.

    Os Detalhes da Atividade mostram que isso faz parte do fluxo de logon esperado onde o usuário seleciona um certificado.

    Captura de tela dos detalhes da atividade nos logs de entrada.

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

    Captura de tela dos detalhes adicionais multifator nos logs de entrada.

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

    Captura de tela da entrada do token de atualização nos logs de entrada.

Testar autenticação multifator

Para o próximo cenário de teste, configure a política de autenticação em que a regra policyOID atenda à 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 atender à autenticação multifator, a entrada do usuário é bem-sucedida sem um segundo fator.

  2. Procure e selecione Entradas.

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

    Captura de tela de várias entradas nos logs de entrada.

    Os Detalhes da Atividade mostram que isso faz parte do fluxo de logon esperado onde o usuário seleciona um certificado.

    Captura de tela dos detalhes de entrada do fator secundário nos logs de entrada.

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

    Captura de tela dos detalhes da tentativa interrompida nos logs de entrada.

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

    Campo Descrição
    Nome da entidade do certificado do usuário Refere-se ao campo de nome da entidade no certificado.
    Associação do certificado de usuário Certificado: nome da entidade de segurança; Atributo de usuário: userPrincipalName; Classificação: 1
    Isso mostra qual campo de certificado SAN PrincipalName foi mapeado para o atributo de usuário userPrincipalName e tinha prioridade 1.
    Nível de autenticação do certificado do 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 do nível de autenticação do certificado do usuário 1.2.3.4
    Isso mostra o valor do OID da política do identificador 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, o usuário ter selecionado o certificado incorreto ou expirado ou devido a um problema com a CRL (lista de certificados revogados). Quando a validação do certificado falha, o usuário vê este erro:

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

Se a CBA falhar em um navegador, mesmo que a falha seja devido ao cancelamento do seletor de certificados, será necessário fechar a sessão do navegador e abrir uma nova sessão para tentar a CBA novamente. Uma nova sessão é necessária porque os navegadores armazenam o certificado em cache. Quando houver outra tentativa com a CBA, o navegador enviará o certificado armazenado em cache durante o desafio TLS, e isso causará falha de credenciais e o erro de validação.

Selecione Mais detalhes para obter informações de registro em log que podem ser enviadas a um administrador, que, por sua vez, pode obter mais informações dos logs de entrada.

Captura de tela dos detalhes do erro.

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

Observação

Se você tentar a CBA novamente em um navegador, ela 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 tela de uma nova tentativa de entrada.

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

Depois que um usuário se autenticar com êxito usando a CBA, o método de autenticação MRU (MostRecentlyUsed) do usuário será definido como CBA. Da próxima vez, quando o usuário inserir seu UPN e selecionar Avançar, ele será levado diretamente para o método CBA e não precisará selecionar Usar 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 a identidade externa

Uma identidade externa não pode executar a autenticação multifator para o locatário de recursos com a CBA do Microsoft Entra. Em vez disso, faça com que o usuário execute a MFA usando a CBA no locatário doméstico e defina as configurações entre locatários para que o locatário do recurso confie na MFA do locatário doméstico.

Para obter mais informações sobre como habilitar a Autenticação multifator de confiança dos locatários do Microsoft Entra, consulte Configurar o acesso entre locatários da colaboração B2B.

Próximas etapas