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

Este artigo descreve conceitos técnicos para explicar como a autenticação baseada em certificado (CBA) do Microsoft Entra funciona. Obtenha a experiência técnica para saber melhor como configurar e gerenciar 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 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 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 Next. O Microsoft Entra ID conclui a descoberta do realm inicial usando o nome do locatário. Ele usa o nome de usuário para pesquisar o usuário no locatário.

   

4. Microsoft Entra ID 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 login, verifique se a CBA está configurada para o locatário.

   Para obter mais informações, consulte Como ativamos 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 Microsoft Entra ID 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 CBA, o cliente redireciona para o endpoint de autenticação de certificado. Para o Microsoft Entra ID público, o ponto de extremidade de autenticação de certificado é https://certauth.login.microsoftonline.com. Para 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 login do usuário e ao endpoint de autenticação de certificados *.certauth.login.microsoftonline.com para seu ambiente de nuvem. Desative a inspeção de TLS no ponto de extremidade de autenticação de certificado para garantir que uma solicitação de certificado do cliente tenha sucesso como parte do handshake de TLS.

   Verifique se desativar a inspeção de TLS também funciona para indicações do emissor com o novo URL. Não codifique a URL com a ID do inquilino. A ID do locatário pode mudar para usuários B2B (negócios para empresas). Use uma expressão regular para permitir que o URL anterior e o novo URL funcionem quando você desativar a inspeção de TLS. Por exemplo, dependendo do proxy, use *.certauth.login.microsoftonline.com ou *certauth.login.microsoftonline.com. Em 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. Microsoft Entra ID solicita um certificado de cliente. O usuário seleciona o certificado do cliente e, em seguida, seleciona OK.

   

7. Microsoft Entra ID 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 certificate satisfaça a MFA, o Microsoft Entra ID conectará o 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. 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 a entrada do usuário for bem-sucedida, o usuário poderá acessar o aplicativo.

Dicas do emissor

As dicas do emissor enviam de volta um indicador de CA confiável como parte do handshake de TLS. A lista de CAs confiáveis é definida pela identidade das CAs que o locatário carrega no repositório confiável 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 confiável, 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 se autenticar com um certificado depois que as dicas do emissor forem disponibilizadas para dar início à propagação.

Os usuários não podem se autenticar usando certificados emitidos por novas autoridades certificadoras até que as informações 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

A CBA do Microsoft Entra 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 a autenticação sem senha ou FIDO2 antes de entrar usando a CBA do Microsoft Entra.

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

A CBA do Microsoft Entra pode ser 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 login por telefone sem senha com a CBA

Para que a entrada por telefone sem senha funcione, primeiro desative a notificação legada 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 ao login 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 funcionam.

3. Selecione Entra ID>Multifactor authentication>Configurações adicionais de autenticação multifatorial 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 principal do 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 login. Nesse caso, é uma entrada sem senha. Selecione Aprovar uma solicitação no meu aplicativo Microsoft Authenticator.

   

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

6. Em 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 vinculação de autenticação

A política de vinculação de autenticação ajuda a definir a força da autenticação como de 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 políticas personalizadas utilizando IssuerAndSubject, PolicyOID, Issuer e PolicyOID no 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 do NIST para os Métodos de Autenticação do Microsoft Entra, que se baseia no NIST 800-63B SP 800-63B, Diretrizes de Identidade Digital: Gerenciamento de Autenticação e Ciclo de Vida.

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.

Regras de vínculo de várias políticas 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, 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 de OID do emissor e de políticas 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 a política OID 1.2.3.4.5 com MFA, somente o certificado A que satisfaça o valor do emissor e o OID da política receberão 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 1.2.3.4.5 e uma credencial derivada B com base nesse certificado que tenha uma OID de política 1.2.3.4.5.6, 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 satisfaz a MFA. A credencial B satisfaz apenas a autenticação de fator único. Se o usuário usou uma credencial derivada no momento do login e foi configurado para Autenticação Multifator (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 associa à autenticação de fator único e o outro associa à MFA), trate o certificado como autenticação de fator único.
5. Regras personalizadas que utilizam CAs do emissor são avaliadas. Se um certificado tiver tanto um OID de política quanto regras de emissor correspondentes, o OID da política sempre será verificado primeiro. Se nenhuma regra de política for encontrada, as vinculaçõ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. (Uma certificação de usuário pode conter múltiplos OIDs de políticas.)
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 vinculaçã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 alternativo da entidade (SAN) no certificado é mapeado para o atributo userPrincipalName do objeto de usuário para identificar o usuário.

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

Microsoft Entra suporta sete métodos para usar vinculaçõ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. Microsoft Entra ID implementa três mapeamentos considerados de baixa afinidade com base em identificadores reutilizáveis. Os outros são considerados associações de alta afinidade. Para obter mais informações, consulte certificateUserIds.

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 inquilino, 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, apenas no OID da política ou apenas no emissor.

Múltiplas regras de vinculaçã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, Microsoft Entra ID 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. Microsoft Graph retorna o atributo priority 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, passe 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 usuário

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

Por exemplo, você tem duas associações de nomes de usuário em PrincipalName mapeadas para UPN, e SubjectKeyIdentifier (SKI) é mapeado(a) 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 mapeamento SKI no atributo certificateUserIds da mesma conta.

Suporte para vários certificados com uma conta de usuário 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 em certificateUserIds poderão 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 da CBA estiver definida para apontar para o campo certificateUserIds para procurar o tipo de associação específico (neste exemplo, IssuerAndSerialNumber), o usuário entrará.

Contas sincronizadas híbridas (M:1)

Para contas sincronizadas, você pode mapear vários certificados. Em Active Directory local, preencha o campo altSecurityIdentities com os valores que identificam cada certificado. Se sua organização usar ligações de alta afinidade (ou seja, autenticação segura) como IssuerAndSerialNumber, os 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 certificateUserIds em Microsoft Entra ID.

Suporte para um certificado com várias contas de usuário 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.

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

Microsoft Entra CBA tem um processo diferente, e nenhuma dica está incluída. Em vez disso, a descoberta do realm inicial identifica a conta pretendida e verifica os valores de certificado. Microsoft Entra CBA também impõe exclusividade no campo certificateUserIds. 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 à fronteira de um único diretório ou tenant. 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 em Microsoft Entra ID dificulta essa abordagem. Em vez disso, o Microsoft Entra Connect deve filtrar os valores por conta para valores únicos que serão inseridos na conta no Microsoft Entra ID. 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, Microsoft Entra Connect aplica o filtro a cada uma das florestas Active Directory com o mesmo objetivo: preencher apenas um valor específico e exclusivo para a conta de nuvem.

Preencha o campo altSecurityIdentities em 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 certificateUserIds em Microsoft Entra ID.

Para sincronizar com certificateUserIds:

1. Configure Microsoft Entra Connect para adicionar o campo alternativeSecurityIds ao metaverso.
2. Para cada floresta do Active Directory local, configure uma nova regra de entrada personalizada com alta precedência (número baixo, inferior a 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 elas não forem preenchidas, será verificado se altSecurityIdentities 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 com base no valor SHA1PublicKey de altSecurityIdentities. Se o valor for developer, filtre com base no valor SubjectKeyIssuer de altSecurityIdentities.

Você pode encontrar vários valores de certificados 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 no Microsoft Entra ID, e 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 em 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 a origem e o certificateUserIds campo como destino.
3. Execute um ciclo de sincronização para concluir a população de dados em Microsoft Entra ID.

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

Escopo da AC (Autoridade de Certificação)

O escopo de CA no Microsoft Entra permite que os administradores de locatário limitem o uso de CAs específicas a grupos de usuários determinados. 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 uma Autoridade Certificadora (AC) é útil em cenários de múltiplas infraestruturas de chave pública (PKI) ou B2B, onde múltiplas Autoridades Certificadoras são utilizadas 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 do Controle de Acesso por meio de logs de autenticação e ferramentas de monitoramento

Um administrador pode usar a delimitação de CA para definir regras que associam uma CA (identificada pelo 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. Microsoft Entra avança pela cadeia de CA. 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 CA

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

2. Vá para Entra ID>métodos de autenticação>autenticação baseada em certificado.

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

   

4. Selecione Adicionar regra.

   

5. Selecione Filtrar CAs por PKI.

   CAs clássicas mostram todas as CAs do repositório de CAs clássicas. 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 Autoridade de Certificação, 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 registro de login mostra sucesso. Na guia Detalhes Adicionais, o SKI da CA da regra de política de escopo é exibido.

  

• Quando uma CBA falha devido a uma regra de escopo de CA, 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 interna do Microsoft Entra 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 utilizado com base nos OIDs de emissor e de política quando os usuários realizam a autenticação baseada em certificado (CBA) para acessar determinados recursos sensíveis. 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 os logs de entrada no Microsoft Entra ID.

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 à 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 do Sujeito e Nome Principal para o objeto de usuário userPrincipalName.

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

Solucionar problemas de login com variáveis dinâmicas nos logs de login

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, os elementos <expectedSKI> e <crlAKI> não são preenchidos com valores corretos.

Quando o login 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. Procure e selecione Logs de entrada.

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

   A primeira entrada solicita o certificado X.509 do usuário. O status Interrompido indica que o Microsoft Entra ID 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 policyOID satisfaça os requisitos de 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 Logins.

   Várias entradas nos logs de registro 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.
   Vinculação de certificado de 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 usuário userPrincipalName e tinha 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 erro do 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 for tentada novamente, o navegador enviará o 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 em busca de mais detalhes sobre os 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 restabelece 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 CBA, o método de autenticação MostRecentlyUsed (MRU) é 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 autenticar-se com êxito em um dispositivo diferente usando um método de autenticação diferente, a MRU será redefinida para o usuário de acordo com o método atualmente autenticado.

Suporte a identidade externa

Um usuário convidado B2B de identidade externa pode usar a CBA no locatário inicial. Se as configurações entre locatários do locatário do recurso forem configuradas para confiar na MFA do locatário inicial, a CBA do usuário no locatário inicial será respeitada. Para mais informações, consulte Configurar acesso cruzado entre locatários para 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
• Aprofundamento técnico para CBA do Microsoft Entra
• Como configurar Microsoft Entra CBA
• Lista de Revogação de Certificados da CBA do Microsoft Entra
• Microsoft Entra CBA em dispositivos Android
• Logon com cartão inteligente no Windows usando Microsoft Entra CBA
• IDs de usuário de certificado
• Como migrar usuários federados
• Perguntas Freqüentes
• Lista de Revogação de Certificados da CBA do Microsoft Entra
• Microsoft Entra CBA em dispositivos Android
• Logon com cartão inteligente no Windows usando Microsoft Entra CBA
• IDs de usuário de certificado
• Como migrar usuários federados
• Perguntas Freqüentes