Aprofundamento técnico técnico de autenticação baseada em certificado 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.

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

Agora vamos percorrer cada etapa:

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

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

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

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

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

    Nota

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

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

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

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

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

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

    Nota

    O administrador de rede deve permitir o acesso à página de início de sessão do utilizador e ao ponto de extremidade *.certauth.login.microsoftonline.com certo para o ambiente de nuvem do cliente. Desative a inspeção TLS no ponto de extremidade certauth para garantir que a solicitação de certificado do cliente seja bem-sucedida como parte do handshake TLS.

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

    A menos que o acesso seja permitido, a autenticação baseada em certificado falhará se você habilitar o próximo recurso de dicas de CA confiável.

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

    Nota

    Não há suporte para dicas de CA confiáveis, portanto, a lista de certificados não pode ter um escopo mais amplo. Estamos a estudar a possibilidade de adicionar esta funcionalidade no futuro.

    Captura de tela do seletor de certificados.

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

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

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

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

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

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 pode precisar de mais configuração para concluir o MFA e comprovar para registrar outros métodos de autenticação quando o usuário estiver no escopo do CBA.

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

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

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

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

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

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

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

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

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

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

Importante

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

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

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

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

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

    Importante

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

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

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

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

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

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

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

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

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

  2. Selecione Entrar com um certificado.

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

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

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

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

    Captura de tela de como selecionar um certificado.

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

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

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

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

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

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

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

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

Pontos fortes do certificado

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

Autenticação de certificado multifator

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

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

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

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

Importante

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

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

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

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

Estamos a trabalhar para corrigir o problema.

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

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

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

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

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

Campo de mapeamento de certificado Exemplos de valores em certificateUserIds Atributos do objeto do usuário Type
NomePrincipal X509:<PN>bob@woodgrove.com userPrincipalName
onPremisesUserPrincipalName
certificateUserIds
baixa afinidade
RFC822Nome X509:<RFC822>user@woodgrove.com userPrincipalName
onPremisesUserPrincipalName
certificateUserIds
baixa afinidade
IssuerAndSubject (pré-visualização) X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest certificateUserIds baixa afinidade
Assunto (pré-visualização) X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest certificateUserIds baixa afinidade
ESQUI X509:<SKI>123456789abcdef certificateUserIds alta afinidade
SHA1Chave Pública X509:<SHA1-PUKEY>123456789abcdef certificateUserIds alta afinidade
IssuerAndSerialNumber (pré-visualização) 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 vinculação de afinidade no nível do locatário e substituir por regras personalizadas (Visualização)

Com esse recurso, um administrador de política de autenticação pode configurar se um usuário pode ser autenticado usando mapeamento de vinculação de nome de usuário de baixa ou alta afinidade. Você pode definir a vinculação de afinidade necessária para o locatário, que se aplica a todos os usuários. Você também pode substituir o valor padrão de todo o locatário criando regras personalizadas com base no OID do Emissor e da Política, ou no OID da 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 do locatário na configuração do método de autenticação CBA ordenada pelo atributo 'priority'. Hoje o conceito de prioridade não está exposto no Portal UX. O gráfico retornará o atributo de prioridade para cada vinculação e eles são usados no processo de avaliação.
  3. Se o locatário tiver a vinculação de alta afinidade habilitada ou se o valor do certificado corresponder a uma regra personalizada que exigiu associação de alta afinidade, remova todas as associações de baixa afinidade da lista.
  4. Avalie cada associação na lista até que ocorra uma autenticação bem-sucedida.
  5. Se o campo de certificado X.509 da associação configurada estiver no certificado apresentado, a ID do Microsoft Entra corresponderá o valor no campo de certificado ao valor do atributo de objeto do usuário.
    1. Se uma correspondência for encontrada, a autenticação do usuário será bem-sucedida.
    2. Se uma correspondência não for encontrada, passe para a próxima vinculação de prioridade.
  6. Se o campo de certificado X.509 não estiver no certificado apresentado, passe para a próxima vinculação de prioridade.
  7. Valide todas as associações de nome de usuário configuradas até que uma delas resulte em uma correspondência e a autenticação do usuário seja bem-sucedida.
  8. Se uma correspondência não for encontrada em nenhuma das associações de nome de usuário configuradas, a autenticação do usuário falhará.

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

Cada um dos atributos de objeto de usuário do Microsoft Entra (userPrincipalName, onPremiseUserPrincipalName, certificateUserIds) disponíveis para vincular certificados a contas de usuário do Microsoft Entra tem uma restrição exclusiva para garantir que um certificado corresponda apenas a uma única conta de usuário do Microsoft Entra. No entanto, o Microsoft Entra CBA suporta vários métodos de vinculação na política de vinculação de nome de usuário 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 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 Entra (M:1)

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

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

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>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 no login e, desde que a Vinculação de Nome de Usuário CBA esteja definida para apontar para o campo certificateUserIds para procurar o tipo de vinculação específico (ou seja, Emissor+SerialNumber neste exemplo), o usuário entrará com êxito.

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

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 para um certificado com várias contas de usuário Entra (1:M)

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

Importante

Não é uma configuração muito segura usar a mesma credencial para autenticar em diferentes contas do Entra ID e recomenda-se não permitir um 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 do locatário 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 ligações de alta afinidade (ou seja, autenticação forte), as ligações dizem Emissor + SerialNumber e SKI, isso pode ter a seguinte aparência:

Ligações de nome de usuário:

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

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

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

Nota

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

Contas sincronizadas híbridas Para contas sincronizadas, a abordagem será diferente. Embora o administrador do locatário 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 do locatário 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 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 (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 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>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

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

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

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

Se o valor em altSecurityIdentities não corresponder a nenhum dos valores de pesquisa no atributo de controle, um AuthoritativeNull será passado. Isso garante que as regras anteriores ou subsequentes que preenchem alternativeSecurityId sejam ignoradas e o resultado fique vazio no 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 completar o preenchimento dos dados no Entra ID.

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

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

O processo de revogação de certificado permite que o administrador revogue 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.

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

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

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

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

Importante

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

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

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

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

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

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

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

Nota

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

Importante

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

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

Como configurar a revogação

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

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

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

Nota

O Azure AD Powershell está planejado para ser descontinuado em 30 de março de 2024. Para saber mais, leia a atualização de descontinuação.

Recomendamos migrar para o Microsoft Graph PowerShell para interagir com o Microsoft Entra ID (anteriormente Azure AD). O Microsoft Graph PowerShell permite acesso a todas as APIs do Microsoft Graph e está disponível no PowerShell 7. Para obter respostas a consultas comuns de migração, consulte as Perguntas frequentes sobre migração.

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

  1. Conecte-se ao PowerShell:

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

            $user = Get-MsolUser -UserPrincipalName test@yourdomain.com`
            $user.StsRefreshTokensValidFrom
    
  3. Configure um novo valor StsRefreshTokensValidFrom para o usuário igual ao carimbo de data/hora atual:

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

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

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

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

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

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

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

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

Noções básicas sobre logs de entrada

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

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

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

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

Captura de ecrã do certificado do utilizador.

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

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

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

Testar a autenticação de fator único

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

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

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

  2. Procure e selecione Logs de login.

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

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

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

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

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

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

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

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

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

Testar autenticação multifator

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

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

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

  2. Procure e selecione Logins.

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

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

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

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

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

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

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

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

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

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

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

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

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

Captura de ecrã dos detalhes do erro.

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

Nota

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

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

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

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

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

Suporte de identidade externa

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

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

Problemas conhecidos

  • Em clientes iOS, há um problema de prompt duplo como parte do fluxo CBA do Microsoft Entra, onde o usuário precisa selecionar Usar o certificado ou cartão inteligente duas vezes. Estamos cientes do problema da experiência de UX e trabalhando para corrigir isso para uma experiência de UX perfeita.

Próximos passos