Partilhar via


Conceitos técnicos de autenticação baseada em certificado do Microsoft Entra

Este artigo descreve conceitos técnicos para explicar como funciona a autenticação baseada em certificado (CBA) do Microsoft Entra. Obtenha o conhecimento técnico para saber melhor como configurar e gerenciar o Microsoft Entra CBA em seu locatário.

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

A figura a seguir mostra o que acontece quando um usuário tenta entrar em um aplicativo em um locatário que tem o Microsoft Entra CBA configurado.

Diagrama que mostra uma visão geral das etapas na autenticação baseada em certificado do Microsoft Entra.

As etapas a seguir resumem o processo do Microsoft Entra CBA:

  1. Um 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. Eles inserem seu nome de usuário na página de entrada do Microsoft Entra e selecionam Avançar. O Microsoft Entra ID conclui a descoberta do território doméstico usando o nome do locatário. Ele usa o nome de usuário para procurar o usuário no locatário.

    Captura de ecrã que mostra a página de início de sessão para o portal MyApps.

  4. O Microsoft Entra ID verifica se o CBA está configurado para o locatário. Se o CBA estiver configurado, 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á configurado para o locatário.

    Para obter mais informações, consulte Como ativamos o Microsoft Entra CBA?.

    Nota

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

    Captura de tela que mostra a opção de usar um certificado ou cartão inteligente.

    Se disponibilizar outros métodos de autenticação, como início de sessão por telefone ou chaves de segurança, os utilizadores poderão ver uma caixa de diálogo de início de sessão diferente.

    Captura de ecrã que mostra a caixa de diálogo de início de sessão se a autenticação FIDO2 também estiver disponível.

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

    O ponto de extremidade executa a autenticação mútua TLS (Transport Layer Security) e solicita o certificado do cliente como parte do handshake TLS. Uma entrada para esta solicitação aparece no registo de entrada.

    Nota

    Um administrador deve permitir o acesso à página de entrada do usuário e ao ponto de extremidade de autenticação de *.certauth.login.microsoftonline.com certificado para seu ambiente de nuvem. Desative a inspeção TLS no ponto de extremidade de autenticação de certificado para garantir que a solicitação de certificado do cliente seja bem-sucedida como parte do handshake TLS.

    Certifique-se de que desativar a inspeção TLS também funcione para dicas do emissor com a nova URL. Não codifice o URL com o ID do locatário. O ID do locatário pode ser alterado para usuários B2B (business-to-business). Use uma expressão regular para permitir que a URL anterior e a nova URL funcionem quando você desativar a inspeção TLS. Por exemplo, dependendo do proxy, use *.certauth.login.microsoftonline.com ou *certauth.login.microsoftonline.com. No ambiente do Azure Government, use *.certauth.login.microsoftonline.us ou *certauth.login.microsoftonline.us.

    A menos que o acesso seja permitido, o CBA falhará se você ativar as dicas do emissor.

  6. O Microsoft Entra ID solicita um certificado de cliente. O usuário seleciona o certificado do cliente e, em seguida, seleciona OK.

    Captura de tela que mostra o seletor de certificados.

  7. O Microsoft Entra ID verifica a lista de revogação de certificados (CRL) para certificar-se de que o certificado não foi revogado e que é válido. O Microsoft Entra ID identifica o utilizador usando a associação de nome de utilizador configurada no tenant para mapear o valor do campo do certificado para o valor do atributo do utilizador.

  8. Se um usuário exclusivo for encontrado por meio de uma política de Acesso Condicional do Microsoft Entra que exija autenticação multifator (MFA) e a regra de vinculação de autenticação de certificado satisfaça a MFA, a ID do Microsoft Entra entra no usuário imediatamente. Se a MFA for necessária, mas o certificado satisfizer apenas um único fator, se o usuário já estiver registrado, o login sem senha e o FIDO2 serão oferecidos como segundos fatores.

  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.

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

Dicas do emissor (visualização)

As dicas do emissor enviam de volta um indicador de CA confiável como parte do handshake TLS. A lista de autoridades de certificação confiáveis é definida como o assunto das autoridades de certificação que o locatário carrega no repositório confiável do Microsoft Entra. Um cliente de navegador ou cliente de aplicativo nativo pode usar as dicas que o servidor envia de volta para filtrar os certificados mostrados no seletor de certificados. O cliente mostra apenas os certificados de autenticação emitidos pelas autoridades de certificação no armazenamento de confiança.

Ativar dicas do emissor

Para ativar as dicas do emissor, marque a caixa de seleção Dicas do emissor . Um administrador de política de autenticação deve selecionar Reconheço depois de certificar-se de que o proxy que tem a inspeção TLS configurada está atualizado corretamente e, em seguida, salvar as alterações.

Nota

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

Captura de tela que mostra como ativar as dicas do emissor.

Nota

Depois de ativar as dicas do emissor, o URL da autoridade de certificação tem o formato <tenantId>.certauth.login.microsoftonline.com.

Captura de tela que mostra o seletor de certificados depois que você ativa as dicas do emissor.

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

Depois de ativar as dicas do emissor e adicionar, atualizar ou excluir CAs do armazenamento confiável, pode ocorrer um atraso de até 10 minutos enquanto as dicas do emissor se propagam de volta para o cliente. Um Administrador de Política de Autenticação deve entrar com um certificado depois que as dicas do emissor forem disponibilizadas para iniciar a propagação.

Os usuários não podem se autenticar usando certificados emitidos por novas autoridades de certificação até que as dicas sejam propagadas. Os usuários veem a seguinte mensagem de erro quando as atualizações do armazenamento confiável da autoridade de certificação estão sendo propagadas:

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

AMF com ACB de fator único

O Microsoft Entra CBA qualifica-se para autenticação de primeiro fator e autenticação de segundo fator.

Aqui estão algumas combinações suportadas:

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

Importante

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

Opções para obter a capacidade de MFA com CBA ativado

O Microsoft Entra CBA pode ser de fator único ou multifator, dependendo da configuração do locatário. Ativar o CBA torna um usuário potencialmente capaz de concluir o MFA. Um usuário que tenha um certificado ou senha de fator único deve usar outro fator para concluir a MFA.

Não permitimos o registo de outros métodos sem primeiro satisfazer a MFA. Se o usuário não tiver nenhum outro método de MFA registrado e estiver no escopo para CBA, o usuário não poderá usar a prova de identidade para registrar outros métodos de autenticação e obter MFA.

Se o usuário compatível com CBA tiver apenas um certificado de fator único e precisar concluir o MFA, escolha uma destas opções para autenticar o usuário:

  • O usuário pode inserir uma senha e usar um certificado de fator único.
  • Um Administrador de Política de Autenticação pode emitir um passe de acesso temporário.
  • Um administrador de política de autenticação pode adicionar um número de telefone e permitir a autenticação de voz ou mensagem de texto para a conta de usuário.

Se o usuário compatível com CBA não tiver recebido um certificado e precisar concluir o MFA, escolha uma destas opções para autenticar o usuário:

  • Um Administrador de Política de Autenticação pode emitir um passe de acesso temporário.
  • Um administrador de política de autenticação pode adicionar um número de telefone e permitir a autenticação de voz ou mensagem de texto para a conta de usuário.

Se o usuário compatível com CBA não puder usar um certificado multifator, como se estiver usando um dispositivo móvel sem suporte a cartão inteligente, mas precisar concluir o MFA, escolha uma destas opções para autenticar o usuário:

  • Um Administrador de Política de Autenticação pode emitir um passe de acesso temporário.
  • O usuário pode registrar outro método MFA (quando o usuário pode usar um certificado multifator em um dispositivo).
  • Um administrador de política de autenticação pode adicionar um número de telefone e permitir a autenticação de voz ou mensagem de texto para a conta de usuário.

Configurar o início de sessão por telefone sem palavra-passe com o CBA

Para que o início de sessão por telemóvel sem palavra-passe funcione, desative primeiro a notificação herdada através da aplicação móvel para o utilizador.

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

  2. Conclua as etapas descritas em Habilitar autenticação de entrada por telefone sem senha.

    Importante

    Certifique-se de selecionar a opção Sem senha . Para quaisquer grupos adicionados ao início de sessão por telefone sem palavra-passe, tem de alterar o valor do modo de Autenticação para Sem Palavra-passe. Se você selecionar Qualquer, o CBA e o login sem senha não funcionarão.

  3. Selecione Entra ID>Multifactor authentication>Configurações adicionais de autenticação multifator baseadas em nuvem.

    Captura de tela que mostra como definir as configurações de MFA.

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

    Captura de ecrã que mostra como remover a notificação através da opção de aplicação móvel.

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

Considere um exemplo de um usuário que tem um certificado de fator único e está configurado para entrada sem senha. Como usuário, você concluiria estas etapas:

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

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

  2. Selecione Usar um certificado ou cartão inteligente.

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

    Se disponibilizar outros métodos de autenticação, como início de sessão por telefone ou chaves de segurança, os utilizadores poderão ver uma caixa de diálogo de início de sessão diferente.

    Captura de ecrã que mostra uma forma alternativa de iniciar sessão com um certificado.

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

    Captura de tela que mostra como selecionar um certificado.

  4. Como o certificado está configurado para ser a força da autenticação de fator único, você precisa de um segundo fator para atender aos requisitos de MFA. Os segundos fatores disponíveis são mostrados na caixa de diálogo de entrada. Neste caso, é um início de sessão sem palavra-passe. Selecione Aprovar uma solicitação no meu aplicativo Microsoft Authenticator.

    Captura de tela que mostra a conclusão de uma solicitação de segundo fator.

  5. Você recebe uma notificação no seu telefone. Selecione Aprovar início de sessão?. Captura de tela que mostra a solicitação de aprovação do telefone.

  6. No Microsoft Authenticator, insira o número que você vê no navegador ou aplicativo.

    Captura de tela que mostra uma correspondência de números.

  7. Selecione Sim e pode autenticar e iniciar sessão.

Política de vinculação de autenticação

A política de vinculação de autenticação ajuda a definir a força da autenticação como fator único ou multifator. Um administrador de política de autenticação pode alterar o método padrão de fator único para multifator. Um administrador também pode definir configurações de política personalizadas usando IssuerAndSubject, PolicyOIDou Issuer e PolicyOID no certificado.

Força do certificado

Os administradores de políticas de autenticação podem determinar se a força do certificado é de fator único ou 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 MFA somente usando certificados. No entanto, um administrador de política de autenticação deve certificar-se de que os certificados estão protegidos por um PIN ou biométrico para serem considerados multifator.

Regras vinculativas de política de autenticação múltipla

Você pode criar várias regras de política de vinculação de autenticação personalizadas usando atributos de certificado diferentes. Um exemplo é usar o emissor e o OID de política, ou apenas o OID de política, ou apenas o emissor.

A sequência a seguir determina o nível de proteção de autenticação quando as regras personalizadas se sobrepõem:

  1. As regras OID do emissor e da política têm precedência sobre as regras OID da política. As regras da política OID têm primazia sobre as regras do emissor do certificado.
  2. As regras OID do emissor e da política são avaliadas primeiro. Se você tiver uma regra personalizada com o emissor CA1 e um OID 1.2.3.4.5 de política com MFA, somente o certificado A que satisfaça o valor do emissor e o OID da política receberá MFA.
  3. As regras personalizadas que usam OIDs de política são avaliadas. Se você tiver um certificado A com OID de política e uma credencial derivada 1.2.3.4.5 B com base nesse certificado que tenha um OID de política de , e a regra personalizada for definida como um OID de 1.2.3.4.5.6política que tenha o valor 1.2.3.4.5 com MFA, somente o certificado A satisfará MFA. A credencial B satisfaz apenas a autenticação de fator único. Se o usuário usou uma credencial derivada durante o login e foi configurado para 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 autenticação de fator único.
  5. As regras personalizadas que usam autoridades de certificação do emissor são avaliadas. Se um certificado tiver regras de política OID e emissor correspondentes, o OID de política será sempre verificado primeiro. Se nenhuma regra de política for encontrada, as ligações do emissor serão verificadas. O OID de política tem uma prioridade de vinculação de autenticação forte mais alta do que o emissor.
  6. 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.
  7. Se um OID de política se ligar a MFA, todos os certificados de usuário que incluem esse OID de política como um dos OIDs qualificam-se como MFA. (Um certificado de usuário pode ter vários OIDs de política.)
  8. Um emissor de certificado só pode ter uma ligação de autenticação forte válida (ou seja, um certificado não pode se vincular à autenticação de fator único e à MFA).

Importante

Atualmente, em um problema conhecido que está sendo resolvido, se um Administrador de Política de Autenticação criar uma regra de política CBA usando o emissor e o OID de política, alguns cenários de registro de dispositivo serão afetados.

Os cenários afetados incluem:

  • Inscrição no Windows Hello for Business
  • Registo da chave de segurança FIDO2
  • Login de telefone sem senha do Windows

O registro de dispositivos com os cenários de ingresso no local de trabalho, ID do Microsoft Entra e associação híbrida do Microsoft Entra não é afetado. As regras de política de CBA que usam o emissor ou o OID de política não são afetadas.

Para atenuar o problema, um Administrador de Política de Autenticação deve concluir uma das seguintes opções:

  • Edite a regra de política CBA que atualmente usa o emissor e o OID da política para remover o emissor ou o requisito de ID da política.
  • Remova a regra de política de autenticação que atualmente usa o emissor e o OID de política e, em seguida, crie uma regra que use apenas o emissor ou o OID de política.

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 alternativo da entidade (SAN) Nome Principal no certificado é mapeado para o userPrincipalName atributo do objeto de usuário para identificar o usuário.

Obtenha maior segurança usando associações de certificado

O Microsoft Entra oferece suporte a sete métodos para usar 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 SubjectKeyIdentifier (SKI) ou SHA1PublicKey. Esses identificadores transmitem uma maior garantia de que apenas um único certificado pode ser usado para autenticar um 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 que são considerados de baixa afinidade com base em identificadores reutilizáveis. Os outros são considerados ligações de alta afinidade. Para obter mais informações, consulte certificateUserIds.

Campo de mapeamento de certificado Exemplos de valores em certificateUserIds Atributos do objeto do usuário Tipo
PrincipalName X509:<PN>bob@woodgrove.com userPrincipalName
onPremisesUserPrincipalName
certificateUserIds
Baixa afinidade
RFC822Name X509:<RFC822>user@woodgrove.com userPrincipalName
onPremisesUserPrincipalName
certificateUserIds
Baixa afinidade
IssuerAndSubject X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest certificateUserIds Baixa afinidade
Subject X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest certificateUserIds Baixa afinidade
SKI X509:<SKI>aB1cD2eF3gH4iJ5kL6-mN7oP8qR= certificateUserIds Alta afinidade
SHA1PublicKey X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR
O SHA1PublicKey valor (hash SHA1 de todo o conteúdo do certificado, incluindo a chave pública) está na propriedade Thumbprint do certificado.
certificateUserIds Alta afinidade
IssuerAndSerialNumber X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
Para obter o valor correto para o número de série, execute este comando e armazene o valor mostrado em certificateUserIds:
Sintaxe:
certutil –dump –v [~certificate path~] >> [~dumpFile path~]
Exemplo:
certutil -dump -v firstusercert.cer >> firstCertDump.txt
certificateUserIds Alta afinidade

Importante

Você pode usar o CertificateBasedAuthentication módulo PowerShell para encontrar o valor correto certificateUserIds para um usuário em um certificado.

Definir e substituir a vinculação de afinidade

Um Administrador de Política de Autenticação pode configurar se os usuários podem se autenticar usando o mapeamento de vinculação de nome de usuário de baixa ou alta afinidade.

Defina a vinculação de afinidade necessária para o locatário, que se aplica a todos os usuários. Para substituir o valor padrão em todo o locatário, crie regras personalizadas com base no emissor e no OID da política, ou apenas no OID da política, ou apenas no emissor.

Várias regras vinculativas de política de nome de usuário

Para resolver várias regras de vinculação de política de nome de usuário, o Microsoft Entra ID usa a associação de prioridade mais alta (menor número):

  1. Procura o objeto de usuário usando o nome de usuário ou UPN.
  2. Obtém a lista de todas as associações de nome de usuário configuradas pelo Administrador de Política de Autenticação na configuração do método CBA ordenada pelo priority atributo. Atualmente, a prioridade não é mostrada no centro de administração. O Microsoft Graph retorna o priority atributo para cada ligação. Em seguida, as prioridades são usadas no processo de avaliação.
  3. Se o locatário tiver a associação de alta afinidade configurada ou se o valor do certificado corresponder a uma regra personalizada que exija associação de alta afinidade, removerá todas as associações de baixa afinidade da lista.
  4. Avalia cada associação na lista até que ocorra uma autenticação bem-sucedida.
  5. Se o campo de certificado X.509 do vínculo configurado estiver no certificado apresentado, a ID do Microsoft Entra irá corresponder o valor no campo de certificado ao valor do atributo de objeto do utilizador.
    • Se for encontrada uma correspondência, a autenticação do utilizador será bem-sucedida.
    • Se uma correspondência não for encontrada, será movida para a próxima vinculação de prioridade.
  6. Se o campo de certificado X.509 não estiver no certificado apresentado, será movido para a próxima vinculação de prioridade.
  7. Valida 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á.

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

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

Importante

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

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

Por exemplo, você tem duas associações de nome de usuário mapeadas PrincipalName para UPN, e SubjectKeyIdentifier (SKI) é mapeado para certificateUserIds. Se você quiser que um certificado seja usado para apenas uma conta, um Administrador de Política de Autenticação deve certificar-se de que a conta tem o UPN presente no certificado. Em seguida, o administrador implementa o SKIcertificateUserIds mapeamento no atributo da mesma conta.

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

Em alguns cenários, uma organização emite vários certificados para uma única identidade. Pode ser uma credencial derivada para um dispositivo móvel, mas também pode ser para um cartão inteligente secundário ou um dispositivo compatível com o titular da credencial X.509, como um YubiKey.

Contas somente na nuvem (M:1)

Para contas somente na nuvem, você pode mapear até cinco certificados para usar preenchendo o certificateUserIds campo com valores exclusivos para identificar cada certificado. Para mapear os certificados, no centro de administração, vá para a guia Informações de autorização .

Se a organização usa associações de alta afinidade como IssuerAndSerialNumber, os valores em certificateUserIds podem se parecer com o exemplo a seguir:

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

Neste exemplo, o primeiro valor representa X509Certificate1. O segundo valor representa X509Certificate2. O usuário pode apresentar qualquer certificado ao entrar. Se a associação de nome de usuário CBA estiver definida para apontar para o certificateUserIds campo para procurar o tipo de associação específico (neste exemplo, IssuerAndSerialNumber), o usuário entrará com êxito.

Contas híbridas sincronizadas (M:1)

Para contas sincronizadas, você pode mapear vários certificados. No Ative Directory local, preencha o altSecurityIdentities campo com os valores que identificam cada certificado. Se sua organização usa associações de alta afinidade (ou seja, autenticação forte) como IssuerAndSerialNumber, os valores podem se parecer com estes exemplos:

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

Neste exemplo, o primeiro valor representa X509Certificate1. O segundo valor representa X509Certificate2. Os valores devem então ser sincronizados com o certificateUserIds campo no Microsoft Entra ID.

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

Em alguns cenários, uma organização exige que um usuário use o mesmo certificado para autenticar em várias identidades. Pode ser para uma conta administrativa ou para uma conta de desenvolvedor ou de serviço temporário.

No Ative Directory local, o altSecurityIdentities campo preenche os valores do certificado. Uma dica é usada durante a entrada para direcionar o Ative Directory para a conta pretendida para verificar se há login.

O Microsoft Entra CBA tem um processo diferente, e nenhuma dica está incluída. Em vez disso, a descoberta do território Home identifica a conta pretendida e verifica os valores do certificado. O Microsoft Entra CBA também impõe exclusividade no certificateUserIds campo. Duas contas não podem preencher os mesmos valores de certificado.

Importante

Usar as mesmas credenciais para autenticar em diferentes contas do Microsoft Entra não é uma configuração segura. Recomendamos que você não permita que um único certificado seja usado para várias contas de usuário do Microsoft Entra.

Contas apenas na nuvem (1:M)

Para contas somente na nuvem, crie várias associações de nome de usuário e mapeie valores exclusivos para cada conta de usuário que usa o certificado. O acesso a cada conta é autenticado usando uma associação de nome de usuário diferente. Esse nível de autenticação se aplica ao limite de um único diretório ou locatário. Um administrador de política de autenticação pode mapear o certificado para usá-lo em outro diretório ou locatário se os valores permanecerem exclusivos por conta.

Preencha o certificateUserIds campo com um valor exclusivo que identifique o certificado. Para preencher o campo, no centro de administração, vá para a guia Informações de autorização .

Se a organização usa associações de alta afinidade (ou seja, autenticação forte) como IssuerAndSerialNumber e SKI, os valores podem se parecer com o exemplo a seguir:

Ligações de nome de usuário:

  • IssuerAndSerialNumber > certificateUserIds
  • SKI > certificateUserIds

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

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

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 usar apenas associações de alta afinidade, o número máximo de contas suportadas será três. Se a organização também usa ligações de baixa afinidade, o número aumenta para sete contas: uma, umaPrincipalName, umaRFC822Name, uma, umaSKI, uma, SHA1PublicKeyuma IssuerAndSubjecte umaIssuerAndSerialNumber.Subject

Contas híbridas sincronizadas (1:M)

Contas sincronizadas exigem uma abordagem diferente. Embora um Administrador de Política de Autenticação possa mapear valores exclusivos para cada conta de usuário que usa o certificado, a prática comum de preencher todos os valores para cada conta no Microsoft Entra ID dificulta essa abordagem. Em vez disso, o Microsoft Entra Connect deve filtrar os valores por conta para valores exclusivos preenchidos na conta na ID do Microsoft Entra. A regra de exclusividade se aplica ao limite de um único diretório ou locatário. Um administrador de política de autenticação pode mapear o certificado para usá-lo em outro diretório ou locatário se os valores permanecerem exclusivos por conta.

A organização também pode ter várias florestas do Ative Directory que contribuem com usuários para um único locatário do Microsoft Entra. Nesse caso, o Microsoft Entra Connect aplica o filtro a cada uma das florestas do Ative Directory com o mesmo objetivo: preencher apenas um valor específico e exclusivo para a conta de nuvem.

Preencha o altSecurityIdentities campo no Ative Directory com os valores que identificam o certificado. Inclua o valor de certificado específico para esse tipo de conta de usuário (como detailed, adminou developer). Selecione um atributo de chave no Ative Directory. O atributo informa à sincronização qual tipo de conta de usuário o usuário está avaliando (como msDS-cloudExtensionAttribute1). Preencha esse atributo com o valor de tipo de usuário que você deseja usar, como detailed, adminou developer. Se a conta for a conta principal do usuário, o valor pode ser vazio ou NULL.

Verifique se as contas são semelhantes a estes exemplos:

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

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

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

Em seguida, você deve sincronizar esses valores com o certificateUserIds campo no Microsoft Entra ID.

Para sincronizar com certificateUserIds:

  1. Configure o Microsoft Entra Connect para adicionar o alternativeSecurityIds campo ao metaverso.
  2. Para cada floresta do Ative Directory local, configure uma nova regra de entrada personalizada com uma precedência alta (um número baixo, abaixo de 100). Adicione uma Expression transformação com o altSecurityIdentities campo como origem. A expressão de destino usa o atributo key selecionado e preenchido e usa o mapeamento para os tipos de usuário definidos.

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) 
)

Neste exemplo, altSecurityIdentities e o atributo msDS-cloudExtensionAttribute1 key é verificado primeiro para ver se eles estão preenchidos. Se eles não estiverem preenchidos, altSecurityIdentities será verificado se está preenchido. Se estiver vazio, defina-o como NULL. Caso contrário, a conta é um cenário padrão.

Também neste exemplo, filtre apenas no IssuerAndSerialNumber mapeamento. Se o atributo key for preenchido, o valor será verificado para ver se é igual a um dos tipos de usuário definidos. No exemplo, se esse valor for detailed, filtre o SHA1PublicKey valor de altSecurityIdentities. Se o valor for developer, filtre o SubjectKeyIssuer valor de altSecurityIdentities.

Você pode encontrar vários valores de certificado de um tipo específico. Por exemplo, você pode ver vários PrincipalName valores ou vários SKI ou SHA1-PUKEY valores. O filtro obtém todos os valores e sincroniza-os no Microsoft Entra ID, não apenas o primeiro que encontra.

Aqui está um segundo exemplo que mostra como enviar por push um valor vazio se o atributo de controle estiver vazio:

IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer")>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    AuthoritativeNull, NULL) 
) 

Se o valor in altSecurityIdentities não corresponder a nenhum dos valores de pesquisa no atributo de controle, um AuthoritativeNull valor será passado. Esse valor garante que as regras anteriores ou subsequentes que são preenchidas alternativeSecurityId sejam ignoradas. O resultado está vazio no Microsoft Entra ID.

Para sincronizar um valor vazio:

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

Certifique-se de que o CBA em cada locatário esteja configurado com as associações de nome de usuário apontando para o certificateUserIds campo para os tipos de campo mapeados a partir do certificado. Agora, qualquer um desses usuários pode apresentar o certificado no login. Depois que o valor exclusivo do certificado é validado em relação ao certificateUserIds campo, o usuário é conectado com êxito.

Escopo da Autoridade de Certificação (CA) (Visualização)

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

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

Principais benefícios

  • Restringe o uso do certificado a grupos de usuários específicos
  • Suporta ambientes PKI complexos através de várias autoridades de certificação
  • Fornece proteção aprimorada contra uso indevido ou comprometimento de certificados
  • Dá visibilidade ao uso da autoridade de certificação por meio de logs de login e ferramentas de monitoramento

Um administrador pode usar o escopo da autoridade de certificação para definir regras que associam uma autoridade de certificação (identificada por seu SKI) a um grupo específico do Microsoft Entra. Quando um usuário tenta autenticar usando um certificado, o sistema verifica se a autoridade de certificação emissora do certificado tem como escopo um grupo que inclui o usuário. O Microsoft Entra prossegue na cadeia de autoridades de certificação. Ele aplica todas as regras de escopo até que o usuário seja encontrado em um dos grupos em todas as regras de escopo. Se o usuário não estiver no grupo com escopo, a autenticação falhará, mesmo que o certificado seja válido.

Configurar o recurso de escopo da autoridade de certificação

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

  2. Vá para Métodos deautenticação>do Entra ID>Autenticação baseada em certificado.

  3. Em Configurar, vá para Política de escopo do emissor do certificado.

    Captura de tela que mostra a política de escopo da autoridade de certificação.

  4. Selecione Adicionar regra.

    Captura de tela que mostra como adicionar uma regra de escopo da autoridade de certificação.

  5. Selecione Filtrar CAs por PKI.

    As autoridades de certificação clássicas mostram todas as autoridades de certificação do repositório de autoridades de certificação clássicas. A seleção de uma PKI específica mostra todas as autoridades de certificação da PKI selecionada.

  6. Selecione uma PKI.

    Captura de tela que mostra o filtro PKI de escopo da autoridade de certificação.

  7. A lista Emissor de certificado mostra todas as autoridades de certificação da PKI selecionada. Selecione uma autoridade de certificação para criar uma regra de escopo.

    Captura de tela que mostra como selecionar uma autoridade de certificação no escopo da autoridade de certificação.

  8. Selecione Adicionar grupo.

    Captura de tela que mostra a opção adicionar grupo no escopo da autoridade de certificação.

  9. Selecione um grupo.

    Captura de tela que mostra a opção selecionar grupo no escopo da autoridade de certificação.

  10. Selecione Adicionar para salvar a regra.

    Captura de tela que mostra a opção Salvar regra no escopo da autoridade de certificação.

  11. Marque a caixa de seleção Eu reconheço e, em seguida, selecione Salvar.

    Captura de tela que mostra a opção de configuração de salvar CBA no escopo da autoridade de certificação.

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

    Captura de tela que mostra como editar ou excluir no escopo da autoridade de certificação.

Limitações conhecidas

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

Entradas de registo de início de sessão

  • O log de entrada mostra o sucesso. Na guia Detalhes Adicionais , o SKI da AC da regra de política de escopo é exibido.

    Captura de tela que mostra o êxito do log de entrada de uma regra de escopo da autoridade de certificação.

  • Quando um CBA falha devido a uma regra de escopo da autoridade de certificação, a guia Informações básicas no log de entrada mostra o código de erro 500189.

    Captura de tela que mostra um erro de log de entrada de escopo da autoridade de certificação.

    Os usuários finais veem a seguinte mensagem de erro:

    Captura de tela que mostra um erro do usuário de escopo da autoridade de certificação.

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

Você pode usar a força de autenticação MFA resistente a phishing interna do Microsoft Entra para criar uma política de autenticação de Acesso Condicional que especifique usar o CBA para acessar um recurso. A política permite apenas 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 autenticação de fator único, MFA ou ambos. Para obter mais informações, consulte Força da autenticação de acesso condicional.

Força CBA com opções avançadas

Na política de método CBA, um Administrador de Política de Autenticação pode determinar a força do certificado usando uma política de vinculação de autenticação no método CBA. Agora você pode 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. Ao criar uma força de autenticação personalizada, vá para Opções avançadas. O 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.

Registos de início de sessão

Os logs de entrada fornecem informações sobre entradas e como seus recursos são usados na organização. Para obter mais informações, consulte Logs de entrada na ID do Microsoft Entra.

Em seguida, considere dois cenários. Em um cenário, o certificado satisfaz a autenticação de fator único. No segundo cenário, o certificado satisfaz o MFA.

Para os cenários de teste, selecione um usuário que tenha uma política de Acesso Condicional que exija MFA.

Configure a política de vinculação de usuário mapeando Nome Alternativo do Assunto e Nome Principal para o userPrincipalName objeto do usuário.

O certificado de usuário deve ser configurado como o exemplo mostrado nesta captura de tela:

Captura de tela que mostra o certificado do usuário.

Solucionar problemas de entrada com variáveis dinâmicas em logs de entrada

Embora os logs de entrada normalmente forneçam todas as informações necessárias para depurar um problema de entrada, às vezes são necessários valores específicos. Os logs de entrada não suportam variáveis dinâmicas, portanto, em alguns casos, os logs de entrada não têm as informações necessárias para depuração.

Por exemplo, o motivo da falha nos logs de entrada pode aparecer "The Certificate Revocation List (CRL) failed signature validation. Expected Subject Key Identifier <expectedSKI> doesn't match CRL Authority Key <crlAK>. Request your tenant administrator to check the CRL configuration." nesse cenário<expectedSKI> e <crlAKI> não são preenchidos com valores corretos.

Quando o login do usuário com o CBA falhar, você poderá copiar os detalhes do log do link Mais detalhes na página de erro. Para obter mais informações, consulte Noções básicas sobre a página de erro 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 satisfaça a IssuerAndSubject autenticação de fator único.

Captura de tela que mostra a configuração da política de autenticação e a autenticação de fator único necessárias.

  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 satisfaz a IssuerAndSubject autenticação de fator único.

  2. Procure e, em seguida, selecione Registos de início de sessão.

    A figura seguinte mostra algumas das entradas que pode encontrar nos registos de início de sessão.

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

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

    Detalhes da atividade mostra que a solicitação faz parte do fluxo de entrada esperado no qual o usuário seleciona um certificado.

    Captura de ecrã que mostra os detalhes da atividade nos registos de início de sessão.

    Detalhes adicionais mostra as informações do certificado.

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

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

    Captura de ecrã que mostra uma entrada de token de atualização nos registos de início de sessão.

Teste MFA

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

Captura de tela que mostra a configuração da política de autenticação mostrando MFA necessária.

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

  2. Procure e, em seguida, selecione Iniciar sessão.

    Várias entradas nos logs de entrada aparecem, incluindo uma entrada com um status Interrompido .

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

    Detalhes da atividade mostra que a solicitação faz parte do fluxo de entrada esperado no qual o usuário seleciona um certificado.

    Captura de ecrã que mostra os detalhes de início de sessão de segundo fator nos registos de início de sessão.

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

    Captura de ecrã que mostra os 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 sujeito no certificado.
    Vinculação de certificado de usuário Certificado: PrincipalName; atributo do usuário: userPrincipalName; Classificação: 1
    Este campo mostra qual campo de certificado SAN PrincipalName foi mapeado para o userPrincipalName atributo de usuário 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
    Este campo 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.

Página de erro do CBA

A ACB pode falhar por várias razões. Os exemplos incluem um certificado inválido, o usuário selecionou o certificado errado ou um certificado expirado, ou ocorre um problema de CRL. Quando a validação do certificado falha, o usuário vê esta mensagem de erro:

Captura de tela que mostra 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, feche a sessão do navegador. Abra uma nova sessão para tentar o CBA novamente. Uma nova sessão é necessária porque os navegadores armazenam certificados em cache. Quando o CBA é repetido, o navegador envia um certificado armazenado em cache durante o desafio TLS, o que causa falha de entrada e o erro de validação.

  1. Para obter informações de registo para enviar a um Administrador de Políticas de Autenticação para obter mais informações dos registos de início de sessão, selecione Mais detalhes.

    Captura de tela que mostra detalhes do erro.

  2. Selecione Outras formas de iniciar sessão e experimente outros métodos de autenticação disponíveis para iniciar sessão.

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

Redefinir a opção de certificado no Microsoft Edge

O navegador Microsoft Edge adicionou um recurso que redefine a seleção de certificado sem reiniciar o navegador.

O usuário conclui as seguintes etapas:

  1. Quando o CBA falha, a página de erro é exibida.

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

  2. À esquerda do URL de endereço, selecione o ícone de cadeado e, em seguida, selecione As suas opções de certificado.

    Captura de tela que mostra a escolha de certificado do navegador Microsoft Edge.

  3. Selecione Redefinir opções de certificado.

    Captura de tela que mostra a redefinição da opção de certificado do navegador Microsoft Edge.

  4. Selecione Redefinir opções.

    Captura de tela que mostra a aceitação de redefinição da opção de certificado do navegador Microsoft Edge.

  5. Selecione Outras formas de iniciar sessão.

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

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

ACB nos métodos mais recentemente utilizados

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

Para redefinir o método MRU, cancele o seletor de certificados e selecione Outras maneiras de entrar. Selecione outro método disponível e, em seguida, conclua a autenticação.

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

Suporte de identidade externa

Um usuário convidado B2B de identidade externa pode usar o CBA no locatário doméstico. Se as configurações de locatário cruzado para o locatário de recurso estiverem configuradas para confiar no MFA do locatário doméstico, o CBA do usuário no locatário doméstico será honrado. Para obter mais informações, consulte Configurar o acesso entre locatários de colaboração B2B. Atualmente, o CBA em um locatário de recurso não é suportado.