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.

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.

   

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

   

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

   

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

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

   Nota

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

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

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

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

   

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

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

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

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

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

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

Ativar dicas do emissor

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

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

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

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

Capacidade de MFA de autenticação baseada em certificado

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

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. ACB (primeiro fator) e chaves de acesso (segundo fator)
2. CBA (primeiro fator) e login por telefone sem senha (segundo fator)
3. Chaves de segurança CBA (primeiro fator) e FIDO2 (segundo fator)

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.

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.

   

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

   

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

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

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

   

2. Selecione Entrar com um certificado.

   

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

   

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

   

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

   

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

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

   

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

MFA com autenticação baseada em certificado como segundo fator (visualização)

CBA pode ser usado como um segundo fator como Password (primeiro fator) e CBA (segundo fator) para obter MFA.

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

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

Pontos fortes do certificado

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

Autenticação de certificado multifator

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ligações de nome de usuário:

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

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

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

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

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

As contas podem ter a seguinte aparência:

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

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

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

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

Etapas para sincronizar com certificateUserIds

1. Configure o Microsoft Entra Connect para adicionar o campo alternativeSecurityIds ao Metaverso
2. Para cada Floresta do AD, configure uma nova regra de entrada personalizada com uma precedência alta (número baixo abaixo de 100). Adicione uma transformação Expression com o campo altSecurityIdentities como origem. A expressão de destino usará o Atributo de Chave que você selecionou e preencheu, bem como o mapeamento para os Tipos de Usuário que você definiu.
3. Por exemplo:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

     

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

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.

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

1. Conecte-se ao PowerShell:

   Connect-MgGraph
   

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

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

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

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

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

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

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

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

Ativar validação de CRL

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

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

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

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

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

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

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

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

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

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

Noções básicas sobre logs de entrada

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

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

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

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

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.

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.

   

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

   

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

   

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

   

Testar autenticação multifator

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

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

2. Procure e selecione Logins.

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

   

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

   

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

   

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

   Campo	Descrição
   Nome 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:

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

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

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

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.

Próximos passos

• Visão geral do Microsoft Entra CBA
• Como configurar o Microsoft Entra CBA
• Microsoft Entra CBA em dispositivos iOS
• Microsoft Entra CBA em dispositivos Android
• Logon de cartão inteligente do Windows usando o Microsoft Entra CBA
• IDs de usuário do certificado
• Como migrar usuários federados
• FAQ
• Solucionar problemas do Microsoft Entra CBA