Partilhar via

Introdução ao Microsoft Entra Kerberos

O Microsoft Entra Kerberos é um protocolo de autenticação nativo da nuvem que faz a ponte entre cenários de identidade híbrida, permitindo o acesso seguro a recursos na nuvem e no local. Ele estende os recursos Kerberos tradicionais ao ecossistema Microsoft Entra, para que as organizações possam modernizar sua infraestrutura de identidade sem sacrificar a compatibilidade com sistemas legados. Ele também permite o logon único (SSO) contínuo para recursos locais para usuários autenticados com credenciais modernas, como chaves de segurança do Windows Hello for Business ou FIDO2.

O Microsoft Entra Kerberos foi introduzido em 2021 para ajudar a preencher a lacuna entre os protocolos de autenticação locais herdados e a identidade moderna na nuvem. Na prática, o Microsoft Entra Kerberos transforma o Microsoft Entra ID em um Centro de Distribuição de Chaves (KDC) baseado em nuvem para autenticação Kerberos. Esse recurso permite que o Microsoft Entra ID emita tíquetes Kerberos para os usuários, estendendo a autenticação Kerberos tradicional além do Ative Directory local.

Em um cenário híbrido, onde as contas existem nos Serviços de Domínio Ative Directory (AD DS) locais e esses usuários são sincronizados com o Microsoft Entra ID, o Microsoft Entra Kerberos desempenha um papel crucial. Ele permite que esses usuários híbridos se autentiquem em recursos locais e na nuvem usando Kerberos sem precisar de uma linha de visão direta para os controladores de domínio. Por exemplo, se um cliente Windows associado ao Microsoft Entra ID acessar um compartilhamento de arquivos ou aplicativo pela Internet, o Microsoft Entra ID poderá emitir os tíquetes Kerberos necessários em nome do ambiente local do Ative Directory.

Para obter mais informações sobre Kerberos no Windows, consulte Visão geral da autenticação Kerberos no Windows Server.

O Microsoft Entra Kerberos funciona com identidades híbridas, bem como com identidades apenas cloud, quando o serviço o suporta.

Identidade híbrida

Uma identidade híbrida refere-se a uma identidade de usuário que existe no AD DS local e na ID do Microsoft Entra. Essas identidades são sincronizadas por meio de ferramentas como o Microsoft Entra Connect, para que os usuários possam acessar recursos locais e baseados na nuvem usando um único conjunto de credenciais.

Essa configuração permite autenticação perfeita e experiências de SSO em todos os ambientes. É ideal para organizações que desejam fazer a transição para a nuvem enquanto mantêm a infraestrutura legada.

Identidade apenas na nuvem (Pré-visualização)

Uma identidade apenas na cloud refere-se a uma conta de utilizador que existe apenas no Microsoft Entra ID (anteriormente Azure AD) e que não tem uma conta correspondente num Active Directory local.

Principais características e benefícios

Autenticação híbrida contínua: o Microsoft Entra Kerberos permite que os usuários cujas contas residem no AD DS local e são sincronizadas com a ID do Microsoft Entra se autentiquem em recursos locais e na nuvem. Ele reduz (e, em alguns casos, elimina) a necessidade de conectividade direta com controladores de domínio.

Por exemplo, quando um cliente Windows associado ao Microsoft Entra ID acessa um compartilhamento de arquivos ou aplicativo pela Internet, o Microsoft Entra ID pode emitir os tíquetes Kerberos necessários como um KDC associado ao recurso.

Suporte de identidade apenas na cloud (Pré-visualização): Identidades apenas na cloud podem agora usar autenticação Kerberos para cargas de trabalho como o Azure Files, sem necessidade de AD DS local. Isto é possibilitado pelo Entra Kerberos, que funciona como um KDC baseado na cloud.

Segurança aprimorada com suporte a credenciais modernas: os usuários podem entrar usando métodos sem senha, como chaves de segurança do Windows Hello for Business ou FIDO2, mas ainda assim acessar recursos locais que têm proteções Kerberos. Essa capacidade permite a autenticação multifator (MFA) e a autenticação sem senha para reduzir os riscos associados ao roubo de senha e ataques de phishing.

Troca segura de tíquetes: O Microsoft Entra Kerberos usa um modelo de troca de TGT para maior segurança.

Associações de grupo escaláveis: o Microsoft Entra Kerberos aborda as limitações tradicionais do Kerberos com associações de grupo grandes ou dinâmicas para melhorar a confiabilidade e a experiência do usuário. Em cenários que envolvem grandes grupos de usuários, o desempenho é otimizado por meio da distribuição automática de carga em todos os controladores de domínio (DCs) dentro de um site. Para implantações em ambientes de Área de Trabalho Virtual do Azure, recomendamos garantir que DCs suficientes estejam disponíveis e geograficamente próximos ao ambiente, para manter a capacidade de resposta.

Como funciona o Microsoft Entra Kerberos

Em cenários híbridos, o Microsoft Entra Kerberos permite que o seu arrendatário Microsoft Entra ID opere como um domínio Kerberos dedicado juntamente com o seu domínio Active Directory no local existente. Quando um utilizador entra num dispositivo Windows que está associado ao Microsoft Entra ID ou associado de forma híbrida, o dispositivo autentica-se com o Microsoft Entra ID e recebe um Token de Atualização Primário (PRT).

Além do PRT, o Microsoft Entra ID emite um Cloud TGT para o reino KERBEROS.MICROSOFTONLINE.COM, que é usado para autenticação de recursos na nuvem. É emitido um TGT parcial separado para aceder a recursos locais, conforme descrito mais adiante neste documento. Neste modelo, o Microsoft Entra ID atua como o KDC para facilitar a autenticação contínua.

Cenários de identidades apenas na cloud (Pré-visualização)

O suporte a identidades apenas na cloud para o Entra Kerberos requer um tenant Microsoft Entra ID com o Entra Kerberos ativado e um dispositivo Windows 10/11 que esteja ligado ao Microsoft Entra.

O suporte ao Microsoft Entra ID com Entra Kerberos para identidades apenas na cloud permite que os anfitriões de sessão unidos à Entra autentiquem e acedam a recursos cloud como partilhas de ficheiros Azure sem depender da infraestrutura tradicional do Active Directory. Esta funcionalidade é essencial para organizações que adotam uma estratégia exclusivamente cloud, pois elimina a necessidade de controladores de domínio, preservando ao mesmo tempo a segurança, controlo de acessos e encriptação de nível empresarial.

Atualmente, as cargas de trabalho suportadas são Azure Files, Azure Virtual Desktop e acesso de autenticação Windows ao Azure SQL Managed Instance.

Fluxo de autenticação

1. Autenticação do utilizador

O utilizador inicia sessão num dispositivo Windows que esteja ligado ao Microsoft Entra ou híbrido.

A Autoridade de Segurança Local (LSA) usa o Provedor de Autenticação na Nuvem (CloudAP) para autenticar via OAuth para o Microsoft Entra ID.

2. Emissão de tokens

Após a autenticação bem-sucedida, o Microsoft Entra ID emite um PRT que contém informações do usuário e do dispositivo. Juntamente com o PRT, o Microsoft Entra ID emite um Cloud TGT para o realm KERBEROS.MICROSOFTONLINE.COM.

O Microsoft Entra ID também emite um OnPremTgt (TGT parcial) que contém o identificador de segurança (SID) do utilizador, mas sem reivindicações de grupo. Este TGT parcial não proporciona acesso direto suficiente aos recursos locais.

Emissão de TGT na nuvem

O Microsoft Entra ID atua como um KDC para recursos de nuvem, emitindo um Cloud TGT para o cliente quando apropriado. O cliente reconhece o tenant do Microsoft Entra ID como um realm Kerberos separado para recursos de nuvem, e o TGT é armazenado no cache de bilhetes Kerberos do cliente. O Cloud TGT é armazenado em cache localmente e pode ser verificado usando o comando PowerShell 'klist cloud_debug'.

O Cloud TGT que o Microsoft Entra ID emite:

  • É para o domínio KERBEROS.MICROSOFTONLINE.COM.
  • Permite o acesso a recursos baseados na nuvem, como Arquivos do Azure, Azure SQL e outros serviços integrados ao Microsoft Entra Kerberos.
  • Contém dados de autorização específicos para serviços de nuvem e são usados diretamente para solicitar tíquetes de serviço Kerberos para recursos de nuvem.
  • É sempre emitido quando um utilizador inicia sessão num dispositivo Windows utilizando credenciais suportadas (por exemplo, Windows Hello para Empresas ou FIDO2).
  • Não depende de controladores de domínio locais.

Observação

O Cloud TGT não substitui o TGT local. É outro ticket que permite o acesso a recursos de nuvem. O TGT local ainda é necessário para acessar recursos locais.

Geração de OnPremTgt para acesso local

Estes pré-requisitos aplicam-se:

  • Os usuários devem ser sincronizados do Ative Directory local para o Microsoft Entra ID por meio do Microsoft Entra Connect.
  • Um objeto de servidor Kerberos deve existir no Ative Directory local e ser sincronizado com o Microsoft Entra ID. Este objeto permite que o Microsoft Entra ID emita um OnPremTgt que os controladores de domínio locais possam resgatar.
  • Os dispositivos devem estar executando o Windows 10 (2004 ou posterior) ou o Windows 11.
  • Os dispositivos devem estar associados ao Microsoft Entra ou associados de forma híbrida.
  • Recomendamos os métodos de autenticação do Windows Hello for Business ou FIDO2 para uma integração ideal.
  • Os controladores de domínio locais devem ser corrigidos para oferecer suporte ao Kerberos Cloud Trust.
  • Garanta visibilidade direta entre dispositivos cliente e controladores de domínio para a troca de tíquetes.

Se o utilizador iniciar sessão usando um método sem palavra-passe (como FIDO2 ou Windows Hello for Business) em dispositivos com Windows 10 (2004 ou posterior) ou Windows 11, o ID Microsoft Entra emite um OnPremTgt para o domínio Active Directory local do utilizador. Este OnPremTgt contém o SID do utilizador, mas sem dados de autorização.

OnPremTgt emitido pelo Microsoft Entra ID

  • Permite o acesso a recursos locais atuando como uma ponte entre o ID do Microsoft Entra e o Ative Directory.
  • Contém dados limitados (por exemplo, o SID do usuário) e nenhuma declaração de grupo. Não é suficiente, por si só, acessar recursos locais.
  • É emitido somente se o ambiente estiver configurado para suportá-lo. Por exemplo, você tem uma configuração de identidade híbrida e um objeto de servidor Microsoft Entra Kerberos no Ative Directory.
  • Deve ser trocado com um controlador de domínio Active Directory local para um TGT completo que inclua o SID do utilizador, PAC completo (todas as pertenças de grupo), chave de sessão e outros dados de controlo de acesso. O TGT completo é então usado para aceder a recursos como partilhas Server Message Block (SMB) ou servidores SQL.

O comando dsregcmd /status mostrará o resultado para ambos os TGT. Mais informações em Resolver problemas dos dispositivos usando o comando dsregcmd.

  • OnPremTgt: Defina o estado para SIM se houver um ticket Cloud Kerberos para aceder a recursos on-premises no dispositivo para o utilizador loginado.
  • CloudTgt: Defina o estado para SIM se houver um ticket Cloud Kerberos para aceder a recursos na nuvem no dispositivo para o utilizador com sessão iniciada.

Microsoft Entra Kerberos TGT e controle de acesso do Ative Directory

Possuir um Microsoft Entra Kerberos TGT para o domínio do Active Directory local de um utilizador não concede automaticamente acesso a um TGT completo do Active Directory.

O Microsoft Entra Kerberos utiliza a lista de permissão e a lista de bloqueio do objeto Read-Only Domain Controller (RODC) para controlar quais utilizadores podem receber TGTs parciais do Microsoft Entra ID para acesso a recursos locais. Este mecanismo é fundamental para limitar a exposição e impor limites de segurança. Este mecanismo é especialmente crítico em ambientes híbridos, nos quais o Microsoft Entra ID emite TGTs parciais que devem ser resgatados junto aos controladores de domínio locais do Active Directory para obter um TGT completo.

Para completar a troca, o utilizador deve estar listado na lista de permissões no objeto RODC e não na lista de bloqueio.

Captura de ecrã das propriedades da conta de utilizador no Ative Directory.

Durante o processo de troca, um Microsoft Entra Kerberos TGT parcial é convertido em um TGT completo do Ative Directory. O Microsoft Entra ID avalia as listas para determinar a elegibilidade de acesso. Se o utilizador estiver na lista de autorização, o Microsoft Entra ID emite o TGT completo. Se o utilizador estiver na lista de bloqueio, o ID Microsoft Entra rejeita o pedido e a autenticação falha.

Como prática recomendada, defina a configuração padrão como Negar. Conceda permissões explícitas de Permitir apenas a grupos autorizados a usar o Microsoft Entra Kerberos.

Importante

Somente o Active Directory local reconhece o TGT parcial. Ter acesso a um TGT parcial não fornece acesso a recursos fora do Ative Directory.

Mapeamento de território

O mapeamento de território é o mecanismo que permite que os clientes Windows determinem qual realm Kerberos contatar quando um usuário estiver acessando um recurso. Esse mecanismo é especialmente importante quando uma organização usa o Ative Directory local e o Microsoft Entra ID no mesmo ambiente.

Windows usa o namespace do serviço (por exemplo, *.file.core.windows.net) para decidir se deve contactar o Active Directory ou o Microsoft Entra ID para um tíquete Kerberos. Como os serviços na nuvem e no local podem compartilhar o mesmo namespace, o Windows não pode distingui-los automaticamente.

Para resolver essa situação, os administradores configuram mapeamentos de nome de host para o realm Kerberos via:

  • Política de Grupo: Configuração do Computador>Modelos Administrativos>Sistema>Kerberos>Definir mapeamentos de nome de host para realms Kerberos
  • Provedor de serviços de configuração de Política do Intune (CSP): Kerberos/HostToRealm

Um exemplo de mapeamento para contoso.com é .file.core.windows.net para KERBEROS.MICROSOFTONLINE.COM. Esse mapeamento informa o Windows para usar o Microsoft Entra Kerberos para instâncias específicas do Azure Files, enquanto o padrão para outras é o Active Directory local.

Informações de tenant do Azure no Microsoft Entra Kerberos

O Microsoft Entra ID atua como um KDC para recursos de nuvem. Ele mantém configurações específicas do locatário que orientam como os tíquetes Kerberos são emitidos e validados:

  • Cloud TGT: Microsoft Entra ID emite este TGT para o domínio KERBEROS.MICROSOFTONLINE.COM. Ele é armazenado no cache de tíquetes Kerberos do cliente e usado para acesso a recursos na nuvem.
  • Proxy KDC: Este protocolo roteia o tráfego Kerberos de forma segura pela Internet para o Microsoft Entra ID. Esse roteamento permite que os clientes obtenham tíquetes sem conectividade direta com controladores de domínio.
  • Reconhecimento de locatário do Azure: a pilha Kerberos usa o mapeamento de realm e a ID do locatário para validar o Cloud TGT e emitir tíquetes de serviço.

3. Solicitação e emissão de tíquete de serviço

Para o acesso do cliente a recursos on-premises (cenário híbrido):

  1. O Microsoft Entra ID emite um TGT parcial.
  2. O cliente entra em contato com um controlador de domínio do Ative Directory local para trocar o TGT parcial por um TGT completo.
  3. O TGT completo é usado para acessar recursos locais, como compartilhamentos SMB ou servidores SQL.

O cliente usa o Cloud TGT para solicitar tíquetes de serviço para recursos de nuvem. Nenhuma interação com o Ative Directory local é necessária. Para acesso do cliente aos recursos da nuvem:

  1. Quando o utilizador acede a um serviço (por exemplo, Azure Files), o cliente solicita um tíquete de serviço da Microsoft Entra ID apresentando o TGT.
  2. O cliente envia uma Solicitação de Serviço de Concessão de Tíquete (TGS-REQ) para o Microsoft Entra ID.
  3. Kerberos identifica o serviço (por exemplo, cifs/mystuff.file.core.windows.net) e mapeia o domínio para KERBEROS.MICROSOFTONLINE.COM. O protocolo KDC Proxy permite a comunicação Kerberos pela Internet.
  4. O Microsoft Entra ID verifica o Cloud TGT e a identidade do utilizador. Ele também procura o SPN (nome da entidade de serviço) solicitado para o recurso Arquivos do Azure registrado na ID do Microsoft Entra.
  5. O Microsoft Entra ID gera um tíquete de serviço e o criptografa usando a chave da entidade de serviço. O Microsoft Entra ID retorna o tíquete para o cliente em uma Resposta de Serviço de Concessão de Tíquete (TGS-REP).
  6. A pilha Kerberos processa o TGS-REP, extrai o ticket e gera um Pedido de Aplicação (AP-REQ).
  7. O AP-REQ é fornecido ao SMB, que o inclui na solicitação ao Azure Files.
  8. Os Arquivos do Azure descriptografam o tíquete e concedem acesso. FSLogix agora pode ler o perfil de utilizador dos Arquivos do Azure e iniciar a sessão da Área de Trabalho Virtual do Azure.

Para acesso do cliente aos recursos da nuvem:

  1. O utilizador com identidade apenas na nuvem acede a um recurso na nuvem (por exemplo, partilha de ficheiros do Azure).
  2. O cliente SMB solicita um ticket de serviço Kerberos para o recurso SPN (por exemplo, cifs/<storageaccount>.file.core.windows.net).
  3. A Entra Kerberos emite o ticket de serviço com base no Cloud TGT. O bilhete inclui a identidade do utilizador no Entra ID e as reclamações do grupo.
  4. O Azure Files valida o bilhete Kerberos contra o Entra ID. A autorização é aplicada usando funções Azure RBAC (por exemplo, Storage File Data SMB Share Contributor).
  5. O utilizador ganha acesso ao recurso se as permissões RBAC forem satisfeitas. Não estão envolvidos ACLs AD ou NTFS locais — a autorização é totalmente baseada na nuvem.

Principais Diferenças em relação ao Kerberos tradicional:

  • Não há KDC local nem Active Directory DS.
  • Sem aplicação do ACL NTFS; usa Azure RBAC.
  • Bilhetes Kerberos emitidos pela Entra Kerberos na nuvem.

Resumo

Característica Computação em Nuvem TGT Ticket de Concessão de Terminal (TGT) no local
Issuer Microsoft Entra ID Active Directory no local (via Exchange)
Domínio KERBEROS.MICROSOFTONLINE.COM Domínio do Ative Directory local
Dados de autorização Específico da nuvem Pertinência completa aos grupos do Active Directory
Troca necessária Não Sim (TGT parcial a TGT total)
Caso de uso Arquivos do Azure, Azure SQL Compartilhamentos SMB, aplicativos herdados
Ferramenta de verificação (macOS) tgt_cloud tgt_ad
Ferramenta de verificação (Windows) klist cloud_debug klist get krbtgt

Cenários

Usar o Microsoft Entra Kerberos para acesso de autenticação do Windows à Instância Gerenciada SQL do Azure

A autenticação Kerberos para o Microsoft Entra ID permite a autenticação do Windows para acesso à Instância Gerida SQL do Azure. A autenticação do Windows para instâncias gerenciadas permite que os clientes movam os serviços existentes para a nuvem, mantendo uma experiência de usuário perfeita. Essa capacidade fornece a base para a modernização da infraestrutura.

Para obter informações detalhadas, consulte O que é a Autenticação do Windows para entidades do Microsoft Entra na Instância Gerenciada SQL do Azure?.

Use o SSO para entrar em recursos locais usando chaves FIDO2

Os usuários do Microsoft Entra Kerberos podem entrar no Windows usando credenciais modernas, como chaves de segurança FIDO2 e, em seguida, acessar recursos tradicionais baseados no Ative Directory.

Para obter informações detalhadas, consulte Habilitar a entrada de chave de segurança sem senha em recursos locais usando a ID do Microsoft Entra.

Habilitar o SSO do Kerberos para recursos do Ative Directory local e do Microsoft Entra ID Kerberos no SSO da plataforma

Junto com o Platform SSO PRT, o Microsoft Entra emite TGTs Kerberos locais e baseados em nuvem. Esses TGTs são então compartilhados com a pilha Kerberos nativa no macOS por meio do mapeamento TGT no SSO da plataforma.

Para obter informações detalhadas, consulte Habilitar o SSO Kerberos para recursos locais do Ative Directory e do Microsoft Entra ID Kerberos no SSO da plataforma.

Armazenar contêineres de perfil com FSLogix para Área de Trabalho Virtual do Azure

Para hospedar perfis de usuário para áreas de trabalho virtuais, você pode armazenar perfis em um compartilhamento de arquivos do Azure acessado por meio do Microsoft Entra Kerberos. O Microsoft Entra Kerberos permite que o Microsoft Entra ID emita os tíquetes Kerberos necessários para acessar o compartilhamento de arquivos por meio do protocolo SMB padrão do setor.

Para obter informações detalhadas, consulte Armazenar contêineres de perfil FSLogix em Arquivos do Azure usando o Microsoft Entra ID em um cenário híbrido.

Ativar a autenticação Kerberos do Microsoft Entra nos Ficheiros do Azure

A autenticação Microsoft Entra Kerberos permite que identidades híbridas, bem como identidades apenas na cloud, acedam a partilhas de ficheiros Azure através da autenticação Kerberos. Este cenário usa a ID do Microsoft Entra para emitir os tíquetes Kerberos necessários para acessar o compartilhamento de arquivos por meio do protocolo SMB.

Para obter informações detalhadas, consulte Habilitar a autenticação Kerberos do Microsoft Entra para identidades híbridas nos Arquivos do Azure.

Considerações de segurança

  • O Microsoft Entra Kerberos não emite TGTs parciais para identidades que não são sincronizadas com o Microsoft Entra ID.
  • O Microsoft Entra Kerberos usa um modelo de troca TGT seguro via KDC Proxy. Este modelo minimiza a exposição a controladores de domínio e reduz a superfície de ataque.
  • Os administradores podem configurar políticas de resolução de grupo para limitar quais grupos estão incluídos nos tíquetes Kerberos. Esses controles são essenciais para gerenciar o tamanho do tíquete e reduzir a exposição a dados de grupo desnecessários.
  • Aconselhamo-lo a manter uma separação clara entre ambientes na nuvem e no local. Desencorajamos a sincronização de contas confidenciais, como krbtgt_AzureAD ao Active Directory local, devido a riscos de escalonamento de privilégios.
  • Use a lista de permissões e a lista de bloqueio do objeto RODC para controlar quais os utilizadores que podem receber TGTs parciais do ID Microsoft Entra para acesso a recursos locais.

Limitações e outras considerações

Suporte para identidades de utilizadores apenas na cloud (Pré-visualização)

Contas de utilizador apenas na cloud, geridas exclusivamente no Microsoft Entra ID, são suportadas para autenticação Kerberos por serviços como Azure Files, Azure Virtual Desktop e acesso através de autenticação Windows à Instância Gerida do Azure SQL.

Restrições do sistema operacional e do dispositivo

O Microsoft Entra Kerberos é suportado em dispositivos Windows 10 (2004 ou posterior) e Windows 11 associados ao Microsoft Entra ou associados de forma híbrida. Alguns recursos dependem de versões e patches específicos do Windows.

Requisitos de conectividade de rede para configuração de ACL

Os usuários podem acessar compartilhamentos de arquivos do Azure pela Internet sem conectividade direta com controladores de domínio. No entanto, configurar listas de controlo de acesso (ACLs) do Windows ou permissões ao nível de ficheiro para identidades híbridas requer acesso livre à rede aos controladores de domínio locais.

Sem suporte a utilizadores convidados ou entre diferentes locatários

Os utilizadores convidados de empresa para empresa ou de outros inquilinos do Microsoft Entra não podem atualmente autenticar-se através do Microsoft Entra Kerberos.

Expiração da palavra-passe

As palavras-passe do principal do serviço para contas de armazenamento expiram a cada seis meses e precisam ser rotacionadas para manter o acesso.

Limites de membros de grupos

Os tíquetes Kerberos têm uma restrição de tamanho que limita o número de SIDs de grupo que você pode incluir. O limite padrão é de 1.010 grupos por ingresso. Se você exceder esse limite, apenas os primeiros 1.010 serão incluídos. A exclusão do restante pode causar falhas de acesso para usuários em grandes organizações.

Incompatibilidade de MFA para autenticação de Arquivos do Azure

A autenticação Kerberos do Microsoft Entra para compartilhamentos de arquivos do Azure não oferece suporte a MFA. As políticas de Acesso Condicional do Microsoft Entra que impõem MFA devem excluir o aplicativo de conta de armazenamento ou os usuários enfrentam falhas de autenticação.

Exclua os Arquivos do Azure das políticas de Acesso Condicional que exigem MFA. Você pode realizar essa tarefa definindo o escopo da política para excluir a conta de armazenamento ou o aplicativo específico que acessa os Arquivos do Azure.

Requisitos de sincronização de atributos

A sincronização adequada dos principais atributos de usuário do Ative Directory local é essencial para que o Microsoft Entra Kerberos funcione. Esses atributos incluem onPremisesDomainName, onPremisesUserPrincipalName, e onPremisesSamAccountName.

Um único método do Active Directory por conta de Armazenamento do Azure

Para autenticação baseada em identidade dos Arquivos do Azure, você pode habilitar apenas um método do Ative Directory de cada vez por conta de armazenamento. Esses métodos incluem o Microsoft Entra Kerberos, o AD DS local e os Serviços de Domínio Microsoft Entra. Alternar entre métodos requer desativar o método atual primeiro.

Configurações de criptografia Kerberos

A criptografia de bilhete de Kerberos com o Microsoft Entra utiliza exclusivamente AES-256. Você pode configurar a criptografia de canal SMB separadamente, com base em suas necessidades.

Introdução ao Microsoft Entra Kerberos

  1. Para autenticar identidades híbridas, deve primeiro configurar o Microsoft Entra Connect para sincronizar utilizadores de AD DS nas instalações com o Microsoft Entra ID. Para obter detalhes, consulte o guia de instalação do Microsoft Entra Connect.

  2. Configurar os Ficheiros do Azure ou outros serviços para usar a autenticação Kerberos do Microsoft Entra. Para obter instruções, consulte Habilitar a autenticação Kerberos do Microsoft Entra.

  3. Verifique se os clientes Windows estão atualizados e configurados para o Microsoft Entra Kerberos.

  4. Monitore e roteie as senhas do principal de serviço conforme necessário.

  5. Use relatórios e ferramentas de monitoramento do Microsoft Entra ID para acompanhar os eventos de autenticação.

Limite de grupo SID em Entra Kerberos (Prévia)

Os tickets Kerberos podem incluir um máximo de 1.010 Identificadores de Segurança (SIDs) para grupos. Isto é um limite de especificação do Windows. Com o Entra Kerberos agora a suportar identidades apenas na cloud (além de identidades híbridas), os tickets devem incluir tanto SIDs de grupo locais como SIDs de grupo na cloud. As grandes empresas frequentemente têm utilizadores em centenas ou milhares de grupos, incluindo membros aninhados e dinâmicos. Se os SIDs de grupo combinados excederem 1.010, o bilhete Kerberos não pode ser emitido e a autenticação falha. Isto é especialmente problemático em cenários de acesso a SMB como o Azure Files, onde as verificações NTFS ACL dependem da pertença completa ao grupo no ticket.

Como solução a curto prazo, as aplicações que usam o Entra Kerberos para identidades apenas na cloud podem adicionar uma Tag no manifesto da sua aplicação. Quando o serviço Kerberos vê esta etiqueta, sabe que o pedido envolve identidades apenas na cloud. Início de sessão e emissão do PRT bem-sucedidos; no entanto, falhas podem ocorrer durante a obtenção do ticket de serviço quando o utilizador acede a um recurso protegido por Kerberos e excede o limite de SIDs do grupo 1010.

Erros típicos do utilizador final

Ficheiros Windows SMB / Azure - Tentativas de mapeamento/montagem podem falhar com erros genéricos de SMB (por exemplo, o erro de sistema 86 ou 1327 pode aparecer noutros conflitos de políticas como MFA). - O acesso pode ter sucesso para utilizadores de grupos mais pequenos, mas falhar intermitentemente para utilizadores fortemente agrupados no mesmo tenant devido a utilizadores excederem o limite de SIDs de grupo 1010.

Iniciar sessão vs. acesso a recursos - Início de sessão e emissão de PRT bem-sucedidos; falhas ocorrem no momento do ticket de serviço (quando o utilizador acede a um recurso protegido por Kerberos).

Entrada no registo de login Entra - O erro 140011 – KerberosUsersGroupNumberExceeded no registo de início de sessão do Entra indica que o processo de emissão do bilhete Kerberos falhou porque a pertença efetiva ao grupo do utilizador excedeu o número máximo permitido de Identificadores de Segurança (SIDs) num ticket Kerberos. O administrador deve reduzir a membresia de grupos para utilizadores afetados (especialmente grupos aninhados/dinâmicos).

Como atualizar o atributo Tags no ficheiro manifest da aplicação

Opção 1: Atualizar as Etiquetas no Portal de Administração do Entra

  1. Inicie sessão no centro de administração Microsoft Entra ou na função de Administrador de Aplicações Cloud.
  2. Navegue para:
    • Entra ID → Registos de aplicações → Selecione a sua aplicação.
  3. Em Gerir, clique em Manifestar.
    • No editor de JSON, localiza a propriedade de tags e adiciona "kdc_enable_cloud_group_sids".
  4. Clica em Guardar para aplicar alterações.

Opção 2: Atualizar Etiquetas usando a Microsoft Graph API (Permissões: Application.ReadWrite.All)

Corpo de solicitação

PATCH https://graph.microsoft.com/v1.0/applications/{applicationObjectId}
Content-Type: application/json
{
   "tags": [
           "kdc_enable_cloud_group_sids"
    ]
}

Opção 3: Atualizar Etiquetas Usando comandos PowerShell

  1. Inicie o PowerShell com privilégios de administrador.

  2. Instale e importe o SDK do Microsoft Graph PowerShell.

    Install-Module Microsoft.Graph -Scope CurrentUser
Import-Module Microsoft.Graph.Authentication
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

  3. Conecte-se ao locatário e aceite tudo.

    Connect-MGGraph -Scopes "Application.ReadWrite.All" -TenantId <tenantId>

  4. Listar atributo certificateUserIds de um determinado usuário.

    Update-MgApplication -ApplicationId "<AppObjectId>" -Tags @("kdc_enable_cloud_group_sids")

Conteúdo relacionado

  • Last updated on