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

Este artigo descreve os conceitos técnicos para explicar como a CBA (autenticação baseada em certificado) do Microsoft Entra funciona. Obtenha a experiência técnica 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 ilustra o que acontece quando um usuário tenta entrar em um aplicativo em um locatário que tem o Microsoft Entra CBA configurado.

As seguintes etapas 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, em seguida, selecione Avançar. A ID do Microsoft Entra conclui a descoberta de realm doméstico usando o nome do locatário. Ele usa o nome de usuário para pesquisar o usuário no locatário.

   

4. A ID do Microsoft Entra verifica se a CBA está configurada para o locatário. Se a CBA estiver configurada, o usuário verá um link para usar um certificado ou cartão inteligente na página de senha. Se o usuário não vir o link de entrada, verifique se a CBA está configurada para o locatário.

   Para obter mais informações, confira Como ativar o Microsoft Entra CBA?.

   Observação

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

   

   Se você disponibilizar outros métodos de autenticação, como conexão telefônica ou chaves de segurança, os usuários poderão ver uma caixa de diálogo de entrada diferente.

   

5. Depois que o usuário seleciona a CBA, o cliente redireciona para o ponto de extremidade de autenticação de certificado. Para a ID pública do Microsoft Entra, o ponto de extremidade de autenticação de certificado é https://certauth.login.microsoftonline.com. Para o Azure Governamental, 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 do TLS. Uma entrada para essa solicitação aparece nos logs de entrada.

   Observação

   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 do 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 do TLS.

   Verifique se desativar a inspeção do TLS também funciona para dicas de emissor com a nova URL. Não codifique a URL com a ID do locatário. A ID do locatário pode mudar para usuários B2B (negócios para empresas). Use uma expressão regular para permitir que a URL anterior e a nova URL funcionem quando você desativar a inspeção do TLS. Por exemplo, dependendo do proxy, use *.certauth.login.microsoftonline.com ou *certauth.login.microsoftonline.com. No Azure Governamental, use *.certauth.login.microsoftonline.us ou *certauth.login.microsoftonline.us.

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

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

   

7. A ID do Microsoft Entra verifica a CRL (lista de certificados revogados) para garantir que o certificado não seja revogado e se ele é válido. O Microsoft Entra ID identificará o usuário usando a associação de nome de usuário configurada no locatário para mapear o valor do campo de certificado para o valor do atributo do usuário.

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

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

Se a entrada do usuário for bem-sucedida, o usuário poderá acessar o aplicativo.

Dicas do emissor (versão prévia)

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

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 I Confirme depois de verificar se o proxy que tem a inspeção TLS configurada está atualizado corretamente e, em seguida, salvar as alterações.

Propagação de atualização do repositório confiável da AC

Depois de ativar dicas do emissor e adicionar, atualizar ou excluir CAs do repositório de confiança, um atraso de até 10 minutos poderá ocorrer 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 novos CAs até que as dicas sejam propagadas. Os usuários veem a seguinte mensagem de erro quando as atualizações do repositório de confiança da AC estão sendo propagadas:

MFA com CBA de fator único

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

Aqui estão algumas combinações com suporte:

• CBA (primeiro fator) e chaves de passe (segundo fator)
• CBA (primeiro fator) e entrada por telefone sem senha (segundo fator)
• CBA (primeiro fator) e chaves de segurança FIDO2 (segundo fator)
• Senha (primeiro fator) e CBA (segundo fator)

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

Opções para obter a funcionalidade de MFA com a CBA habilitada

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

Não permitimos o registro de outros métodos sem primeiro satisfazer a MFA. Se o usuário não tiver nenhum outro método MFA registrado e estiver no escopo da 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 a 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 emitido um certificado e precisar concluir a 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 estivesse usando um dispositivo móvel sem suporte a cartão inteligente, mas precisar concluir a 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 a entrada de telefone sem senha com a CBA

Para que a entrada por telefone sem senha funcione, primeiro desative a notificação herdada por meio do aplicativo móvel para o usuário.

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 de telefone sem senha.

   Importante

   Verifique se você selecionou a opção Sem senha . Para todos os grupos que você adicionar à entrada de telefone sem senha, você deve alterar o valor do modo de Autenticação para Sem Senha. Se você selecionar Any, CBA e entrada sem senha não funcionarem.

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

   

4. Em Opções de Verificação, desmarque a Notificação por meio da caixa de seleção do aplicativo móvel e selecione Salvar.

   

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. Insira o nome da entidade de usuário (UPN) e selecione Avançar.

   

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

   

   Se você disponibilizar outros métodos de autenticação, como conexão telefônica ou chaves de segurança, os usuários poderão ver uma caixa de diálogo de entrada diferente.

   

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

   

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. Nesse caso, é uma entrada sem senha. Selecione Aprovar uma solicitação em meu aplicativo Microsoft Authenticator.

   

5. Você recebe uma notificação em seu telefone. Selecione Aprovar entrada?.

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

   

7. Selecione Sim e você pode autenticar e entrar.

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

A política de associaçã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 configurar configurações de política personalizadas usando IssuerAndSubject, PolicyOIDou Issuer no PolicyOID certificado.

Força do certificado

Os Administradores de Política 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 NIST para os Métodos de Autenticação do Microsoft Entra, que se baseiam em NIST 800-63B SP 800-63B, Diretrizes de Identidade Digital: Autenticação e Ciclo de Vida Mgmt.

Autenticação de certificado multifator

Quando um usuário tem um certificado multifator, ele só pode executar mfa usando certificados. No entanto, um Administrador de Política de Autenticação deve garantir que os certificados sejam protegidos por um PIN ou biometria para serem considerados multifatores.

Várias regras de associação de política de autenticação

Você pode criar várias regras de política de associação de autenticação personalizada usando atributos de certificado diferentes. Um exemplo é usar o emissor e o OID de política, ou apenas o OID da 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 de OID de política. As regras de OID de política terão prioridade sobre as regras do emissor do certificado.
2. As regras OID do emissor e da política são avaliadas primeiro. Se você tiver uma regra personalizada com o emissor CA1 e o 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 1.2.3.4.5 política e uma credencial derivada B com base nesse certificado que tenha uma OID de 1.2.3.4.5.6política e a regra personalizada for definida como uma OID de política que tenha o valor 1.2.3.4.5 com MFA, apenas o certificado A atenderá à MFA. A credencial B satisfaz apenas a autenticação de fator único. Se o usuário usou uma credencial derivada durante a entrada e foi configurado para MFA, o usuário será solicitado a 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 associa à autenticação de fator único e o outro associa à MFA), trate o certificado como autenticação de fator único.
5. As regras personalizadas que usam CAs do emissor são avaliadas. Se um certificado tiver regras de OID e emissor de política correspondentes, a OID da política sempre será verificada primeiro. Se nenhuma regra de política for encontrada, as associações do emissor serão verificadas. O OID de política tem uma prioridade de associação de autenticação forte mais alta do que o emissor.
6. Se uma AC se associar à MFA, todos os certificados de usuário emitidos por essa AC se qualificarão como MFA. A mesma lógica se aplica à autenticação de fator único.
7. Se uma OID de política se associar à MFA, todos os certificados de usuário que incluem essa OID de política como um dos OIDs se qualificarão como MFA. (Um certificado de usuário pode ter vários OIDs de política.)
8. Um emissor de certificado só pode ter uma associação válida de autenticação forte (ou seja, um certificado não pode ser associado à autenticação de fator único e à MFA).

Política de associação de nome de usuário

A política de associação de nome de usuário ajuda a validar o certificado do usuário. Por padrão, o nome da entidade alternativa (SAN) Principal Name no certificado é mapeado para o userPrincipalName atributo do objeto de usuário para identificar o usuário.

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

O Microsoft Entra dá 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 você não pode reutilizar, como SubjectKeyIdentifier (SKI) ou SHA1PublicKey. Esses identificadores transmitem uma garantia mais alta de que apenas um único certificado pode ser usado para autenticar um usuário.

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

Definir e substituir associação de afinidade

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

Defina a associaçã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 de associação de política de nome de usuário

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

1. Pesquisa 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 associação. Em seguida, as prioridades são usadas no processo de avaliação.
3. Se o locatário tiver uma 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 do certificado X.509 da associação configurada estiver no certificado apresentado, o Microsoft Entra ID combinará o valor no campo de certificado com o valor do atributo de objeto do usuário.
   • Se uma correspondência for encontrada, a autenticação do usuário será bem-sucedida.
   • Se uma correspondência não for encontrada, passará para a próxima associação de prioridade.
6. Se o campo de certificado X.509 não estiver no certificado apresentado, passará para a próxima associaçã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 nas associações de nome de usuário configuradas, a autenticação do usuário falhará.

Proteger 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 associar certificados a contas de usuário do Microsoft Entra (userPrincipalNameonPremiseUserPrincipalNamee 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 dá suporte a vários métodos de associação na política de associaçã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.

Por exemplo, você tem duas associações de nome de usuário mapeadas PrincipalName para UPN, e SubjectKeyIdentifier (SKI) é mapeada para certificateUserIds. Se você quiser que um certificado seja usado apenas para uma única conta, um Administrador de Política de Autenticação deverá verificar se a conta tem o UPN que está presente no certificado. Em seguida, o administrador implementa o SKI mapeamento no certificateUserIds 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 com suporte para credenciais X.509, como um YubiKey.

Contas somente na nuvem (M:1)

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

Se a organização usar associações de alta afinidade como IssuerAndSerialNumber, os valores poderão certificateUserIds ser semelhantes ao 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 um dos certificados na entrada. 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 sincronizadas híbridas (M:1)

Para contas sincronizadas, você pode mapear vários certificados. No Active Directory local, preencha o altSecurityIdentities campo com os valores que identificam cada certificado. Se sua organização usar associações de alta afinidade (ou seja, autenticação forte), IssuerAndSerialNumberos valores poderão ser semelhantes a 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. Em seguida, os valores devem ser sincronizados com o campo na ID do certificateUserIds Microsoft Entra.

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 se autenticar em várias identidades. Pode ser para uma conta administrativa ou para um desenvolvedor ou uma conta de serviço temporária.

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

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

Contas somente 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 poderá 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 identifica o certificado. Para preencher o campo, no centro de administração, acesse a guia Informações de Autorização .

Se a organização usar associações de alta afinidade (ou seja, autenticação forte) como IssuerAndSerialNumber e SKI, os valores poderão ser semelhantes ao exemplo a seguir:

Associações de nome de usuário:

• IssuerAndSerialNumber > certificateUserIds
• SKI > certificateUserIds

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

Agora, quando um dos usuários apresenta o mesmo certificado na entrada, 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 associação.

Contas sincronizadas híbridas (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 na ID do Microsoft Entra 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 poderá 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 Active 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 Active Directory com o mesmo objetivo: preencher apenas um valor específico e exclusivo para a conta de nuvem.

Preencha o altSecurityIdentities campo no Active 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 Active 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 primária do usuário, o valor poderá estar 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 campo na ID do certificateUserIds Microsoft Entra.

Para sincronizar com certificateUserIds:

1. Configure o Microsoft Entra Connect para adicionar o alternativeSecurityIds campo ao metaverso.
2. Para cada floresta do Active 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 a origem. A expressão de destino usa o atributo de chave que você selecionou e preencheu 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 de chave são verificados primeiro para ver se eles são preenchidos. Se eles não forem preenchidos, altSecurityIdentities será verificado se ele está preenchido. Se estiver vazio, defina-o como NULL. Caso contrário, a conta é um cenário padrão.

Também neste exemplo, filtre somente no IssuerAndSerialNumber mapeamento. Se o atributo de chave for preenchido, o valor será verificado para ver se ele é 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 os sincroniza na ID do Microsoft Entra, não apenas no primeiro que ele encontra.

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

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

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

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 a origem e o certificateUserIds campo como destino.
3. Execute um ciclo de sincronização para concluir a população de dados na ID do Microsoft Entra.

Verifique se a CBA em cada locatário está configurada com as associações de nome de usuário apontando para o certificateUserIds campo para os tipos de campo mapeados do certificado. Agora, qualquer um desses usuários pode apresentar o certificado na entrada. Depois que o valor exclusivo do certificado for validado no certificateUserIds campo, o usuário será conectado com êxito.

Escopo da AC (Autoridade de Certificação) (versão prévia)

O escopo de AC 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 aprimora a segurança e a capacidade de gerenciamento da CBA, garantindo que somente usuários autorizados possam se autenticar usando certificados emitidos por ACs específicas.

O escopo de AC é útil em cenários de várias PKI ou B2B em que várias ACs são usadas em diferentes populações de usuários. Ele ajuda a impedir o acesso não intencional e dá suporte à conformidade com políticas organizacionais.

Principais benefícios

• Restringe o uso de certificado a grupos de usuários específicos
• Dá suporte a ambientes PKI complexos por meio de vários CAs
• Fornece proteção aprimorada contra uso indevido ou comprometimento do certificado
• Fornece visibilidade sobre o uso da AC por meio de logs de entrada e ferramentas de monitoramento

Um administrador pode usar o escopo de AC para definir regras que associam uma AC (identificada por sua SKI) a um grupo específico do Microsoft Entra. Quando um usuário tenta autenticar usando um certificado, o sistema verifica se a AC emissora do certificado está no escopo de um grupo que inclui o usuário. O Microsoft Entra continua a cadeia de ac. 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 de outra forma.

Configurar o recurso de escopo da AC

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

2. Acesse osmétodos> de Autenticação de ID> do Entracom autenticação baseada em certificado.

3. Em Configurar, acesse a política de escopo do emissor do certificado.

   

4. Selecione Adicionar regra.

   

5. Selecione Filtrar CAs por PKI.

   As ACs clássicas mostram todos os CAs do repositório de AC clássico. Selecionar uma PKI específica mostra todos os CAs da PKI selecionada.

6. Selecione uma PKI.

   

7. A lista de emissores de certificado mostra todos os CAs da PKI selecionada. Selecione uma CA para criar uma regra de escopo.

   

8. Selecione Adicionar grupo.

   

9. Selecione um grupo.

   

10. Selecione Adicionar para salvar a regra.

    

11. Selecione a caixa de seleção I Confirme e, em seguida, selecione Salvar.

    

12. Para editar ou excluir uma política de escopo de AC, selecione "..." na linha da regra. Para editar a regra, selecione Editar. Para excluir a regra, selecione Excluir.

    

Limitações conhecidas

• Somente um grupo pode ser atribuído por CA.
• Há suporte para no máximo 30 regras de escopo.
• O escopo é aplicado no nível da CA intermediária.
• A configuração inadequada poderá resultar em bloqueios de usuário se não existirem regras de escopo válidas.

Entradas de log de login

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

  

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

  

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

  

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

Você pode usar a força de autenticação MFA resistente a Phishing do Microsoft Entra interna para criar uma política de autenticação de Acesso Condicional que especifica usar a CBA para acessar um recurso. A política permite apenas métodos de autenticação que são resistentes a phishing, como CBA, chaves de segurança FIDO2 e Windows Hello para Empresas.

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

Força da 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 associaçã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 de política quando os usuários executam a 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 os usuários que podem acessar recursos. Para obter mais informações, consulte Opções avançadas para a força de autenticação de acesso condicional.

Logs de entrada

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 a 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 associação de usuário mapeando Nome Alternativo da Entidade e Nome principal para o objeto de userPrincipalName usuário.

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

Solucionar problemas de entrada com variáveis dinâmicas nos 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 dão suporte a 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 mostrar "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." neste cenário<expectedSKI> e <crlAKI> não é preenchido com valores corretos.

Quando a entrada do usuário com a 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 erros da 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 IssuerAndSubject regra satisfaça a autenticação de fator único.

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

2. Pesquise e selecione logs de entrada.

   A próxima figura mostra algumas das entradas que você pode encontrar nos logs de entrada.

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

   

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

   

   Detalhes adicionais mostram as informações do certificado.

   

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

   

Testar MFA

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

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

2. Pesquise e selecione Entradas.

   Várias entradas nos logs de entrada são exibidas, incluindo uma entrada com um status interrompido .

   

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

   

   A entrada com um status interrompido exibe 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 do usuário	Refere-se ao campo de nome da entidade no certificado.
   Associação de certificado do usuário	Certificado: PrincipalName; atributo de usuário: userPrincipalName; Classificação: 1 Esse campo mostra qual campo de certificado SAN PrincipalName foi mapeado para o atributo de userPrincipalName usuário e foi a prioridade 1.
   Nível de autenticação de certificado do usuário	multiFactorAuthentication
   Tipo de nível de autenticação de certificado do usuário	PolicyId Esse 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 do usuário	1.2.3.4 Isso mostra o valor do OID da política do identificador do certificado.

Página de erros da CBA

A CBA pode falhar por várias razões. Os exemplos incluem um certificado inválido, o usuário selecionou o certificado incorreto 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:

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

1. Para obter informações de log para enviar a um Administrador de Política de Autenticação para obter mais informações nos logs de entrada, selecione Mais detalhes.

   

2. Selecione Outras maneiras de entrar e tente outros métodos de autenticação disponíveis para entrar.

   

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 a CBA falha, a página de erro é exibida.

   

2. À esquerda da URL do endereço, selecione o ícone de bloqueio e, em seguida, selecione Suas opções de certificado.

   

3. Selecione Redefinir opções de certificado.

   

4. Selecione Opções de Redefinição.

   

5. Selecione Outras maneiras de entrar.

   

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

CBA em métodos MostRecentlyUsed

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

Para redefinir o método MRU, cancele o seletor de certificado e selecione Outras maneiras de entrar. Selecione outro método disponível e 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, a MRU será redefinida para o usuário para o método conectado no momento.

Suporte a identidade externa

Um usuário convidado B2B de identidade externa pode usar a CBA no locatário da casa. Se as configurações entre locatários do locatário do recurso forem configuradas para confiar na MFA do locatário residencial, a CBA do usuário no locatário da casa será respeitada. Para obter mais informações, consulte Configurar o acesso entre locatários de colaboração B2B. Atualmente, não há suporte para CBA em um locatário de recurso.

Conteúdo relacionado

• Visão geral do Microsoft Entra CBA
• Configurar o Microsoft Entra CBA
• Lista de revogação de certificados do Microsoft Entra CBA
• CBA do Microsoft Entra em dispositivos iOS
• CBA do Microsoft Entra em dispositivos Android
• Entrada de cartão inteligente do Windows usando o Microsoft Entra CBA
• IDs de usuário de certificado
• Migrar usuários federados
• Perguntas Freqüentes
• Solucionar problemas da CBA do Microsoft Entra