Windows Hello for Business: Cloud Kerberos Trust para PMEs Híbridas

Numa PME híbrida — dispositivos no Microsoft Entra ID, ficheiros e aplicações no Active Directory local — o login passwordless sempre esbarrou na mesma parede: o Windows Hello autentica bem na cloud, mas os recursos AD continuam a querer Kerberos com passwords e certificados. O cloud Kerberos trust resolve isso: o Entra ID torna-se a âncora de confiança do Kerberos, os utilizadores fazem login com PIN ou biometria e recebem acesso SSO aos recursos AD locais sem password — e sem PKI. Este artigo explica o modelo, a implementação passo a passo com Intune, e os casos em que não é o modelo certo.

Porquê o Cloud Kerberos Trust e Não Key Trust ou Certificate Trust

O Windows Hello for Business tem três modelos de confiança para autenticar em AD local num ambiente híbrido, e a Microsoft é explícita na recomendação: o cloud Kerberos trust é o modelo recomendado face ao key trust. A comparação prática:

Modelo PKI necessária Complexidade Notas
Certificate trust Sim — certificados de DC e de utilizador Elevada Modelo mais antigo; precisa de CA empresarial gerida
Key trust Sim — certificados de DC apenas Média Chaves escritas no AD via Entra Connect
Cloud Kerberos trust Não Baixa Único modelo híbrido sem dependência de PKI

O cloud Kerberos trust partilha infraestrutura com o sign-in FIDO2/passwordless (Microsoft Entra Kerberos) — quem já activou passkeys com SSO a recursos AD já tem a base montada.

Como Funciona: O Papel do Partial TGT

O mecanismo é elegante e reutiliza o Kerberos clássico:

  1. O utilizador faz login no dispositivo com Windows Hello (PIN ou biometria — métodos baseados em chave. A password não conta para este fluxo..
  2. O dispositivo recebe do Entra ID um Cloud TGT para o realm KERBEROS.MICROSOFTONLINE.COM — serve recursos cloud-integrados como Azure Files.
  3. Quando o utilizador acede a um recurso AD local (ex: share de ficheiros), o cliente envia ao controlador de domínio o partial TGT (ticket de referral) que recebeu do Entra ID. Este ticket contém só o SID do utilizador e é assinado pela Microsoft Entra Kerberos.
  4. O DC valida o partial TGT e devolve um TGT completo do AD — o SSO segue daí em diante como Kerberos normal.

A peça que torna isto possível do lado AD é o objecto AzureADKerberosServer: criado no OU de Domain Controllers, funciona como um krbtgt de leitura que o Entra ID usa para assinar os partial TGTs. Os DCs confiam neles porque partilham a chave. É a mesma mecânica que o Medium de administração de identidades da Microsoft descreve para FIDO2 — o cloud Kerberos trust aplica o mesmo mecanismo ao Windows Hello.

Pré-requisitos na PME Híbrida

Antes de configurar a política:

  • Microsoft Entra Kerberos implementado no tenant e no domínio (o módulo PowerShell AzureADHybridAuthenticationManagement, com um Global Administrator e um Domain Admin a criar o objecto por domínio: Set-AzureADKerberosServer -Domain <dominio> ou o cmdlet do módulo novo).
  • Dispositivos Entra joined ou Entra hybrid joined, Windows 10 2004+ ou Windows 11.
  • Capacidade de DCs read-write em cada site AD onde os utilizadores vão autenticar (planeamento de capacidade oficial).
  • TPM nos dispositivos para as chaves do Hello (recomendado — a política pode exigir security device).
  • Contas de administrador de domínio em grupos privilegiados não podem usar cloud Kerberos trust para testes — a restrição aplica-se a quem está em Domain Admins.

Implementação com Intune: Passo a Passo

A implementação tem duas partes: criar o objecto Kerberos no AD (uma vez) e aplicar a política aos dispositivos.

Passo 1 — Microsoft Entra Kerberos (o objecto de confiança):

# Módulo MicrosoftEntraKerberos (ou AzureADPreview em versões antigas)
# Corrido por um Domain Admin, com consentimento do Global Administrator
Set-AzureADKerberosServer -Domain "pme.local" -UserPrincipalName [email protected]

O comando cria o objecto Kerberos server no AD local e o lado Entra correspondente. Verificar no AD: um utilizador AZUREADKERBEROS$ (ou similar) na OU Domain Controllers.

Passo 2 — política no Intune (Settings Catalog):

Categoria Definição Valor
Windows Hello for Business Use Windows Hello For Business true
Windows Hello for Business Use Cloud Trust For On-Prem Auth Enabled
Windows Hello for Business Require Security Device true

Atribuir a política ao grupo de dispositivos/utilizadores alvo. Em alternativa GPO: as mesmas definições nos Administrative Templates de Windows Hello for Business (“Use cloud trust for on-premises authentication”).

Passo 3 — provisionamento e validação:

O provisionamento do Windows Hello arranca na primeira sessão do utilizador após a política chegar, se os pré-requisitos passarem. O cloud Kerberos trust acrescenta um pré-requisito próprio: o check de partial TGT — valida que o Entra Kerberos está configurado para o domínio e tenant do utilizador. O estado vê-se no log de eventos User Device Registration (Applications and Services Logs > Microsoft > Windows) e nos três estados do check: Yes, No, Not Tested.

Do lado cliente, a política CloudKerberosTicketRetrievalEnabled = 1 (aplicada pela mesma configuração) faz os clientes pedirem o Cloud TGT no login. Sem ela, não há tickets cloud.

Verificação: Como Confirmar que o Fluxo Funciona

  1. Login com Windows Hello (PIN) num dispositivo híbrido.
  2. Aceder a um recurso AD local (share de ficheiros, app com auth Kerberos) — deve abrir sem password.
  3. Confirmar os tickets: klist deve mostrar o TGT do realm KERBEROS.MICROSOFTONLINE.COM (Cloud TGT) e, após o acesso ao recurso local, o TGT do domínio AD (obtido via partial TGT).
  4. Nos logs de sign-in do Entra (sign-in logs), o método de autenticação mostra o Windows Hello. Nos controladores, o evento de validação do partial TGT.

Limitações e Cenários em que Não é o Modelo Certo

  • Contas privilegiadas. Membros de Domain Admins e grupos equivalentes não podem usar cloud Kerberos trust para os seus logins — os admin devem ter contas separadas de qualquer forma.
  • Certificate trust existente. Cloud Kerberos trust e certificate trust não coexistem no mesmo parque: quem já tem certificate trust em produção precisa de planear a transição (a Microsoft recomenda cloud trust nos novos deployments).
  • Cenários sem Entra Kerberos. Ambientes puramente on-premises (sem Entra ID) continuam com os modelos clássicos — o cloud trust exige Entra ID como âncora.
  • MacOS e Linux: macOS tem suporte via Platform SSO com perfil Kerberos SSO (obtém tickets cloud e AD). O Linux fica fora do fluxo Windows Hello.

Erros Comuns

  • Aplicar a política tenant-wide por engano. O policy de enrollment do Intune aplica-se a tudo. Para controlo por grupo, desactivar o tenant-wide e usar Settings Catalog atribuído.
  • Esquecer o Set-AzureADKerberosServer. Sem o objecto, o partial TGT não é emitido e o check de provisionamento falha — o log User Device Registration mostra o estado Not Tested/No.
  • Testar com uma conta de Domain Admin. O fluxo não funciona para contas em grupos privilegiados. Usar uma conta de utilizador normal para validar.
  • Esperar SSO a apps com NTLM. O caminho é Kerberos. As aplicações que só aceitam NTLM precisam de avaliação separada (ver o artigo de migração NTLM→Kerberos).
  • Confundir Cloud TGT com partial TGT. O primeiro serve recursos cloud. O segundo é a referência que o DC troca pelo TGT AD completo.

Artigos Relacionados