Partilhar via

Planear uma implementação de Windows Hello para Empresas

Este guia de planejamento ajuda você a entender as diferentes topologias, arquiteturas e componentes que abrangem a infraestrutura do Windows Hello para Empresas.

O guia explica a função de cada componente no Windows Hello para Empresas e como certas decisões de implantação afetam outros aspectos da infraestrutura.

Dica

Se tiver um inquilino Microsoft Entra ID, pode utilizar o nosso Assistente online e interativo Sem Palavra-passe, que percorre as mesmas opções em vez de utilizar o nosso guia manual abaixo. O Assistente sem Palavra-passe está disponível no Centro de administração do Microsoft 365.

Uso do guia

Existem muitas opções disponíveis para implementar Windows Hello para Empresas, garantindo a compatibilidade com várias infraestruturas organizacionais. Embora o processo de implementação possa parecer complexo, a maioria das organizações irá descobrir que já implementou a infraestrutura necessária. É importante ter em atenção que Windows Hello para Empresas é um sistema distribuído e requer um planeamento adequado em várias equipas dentro de uma organização.

Este guia visa simplificar o processo de implementação ao ajudá-lo a tomar decisões informadas sobre cada aspeto da implementação do Windows Hello para Empresas. Fornece informações sobre as opções disponíveis e ajuda a selecionar a abordagem de implementação mais adequada ao seu ambiente.

Como proceder

Leia este documento e registe as suas decisões. Quando terminar, deve ter todas as informações necessárias para avaliar as opções disponíveis e para determinar os requisitos da implementação Windows Hello para Empresas.

Existem sete áreas main a considerar ao planear uma implementação Windows Hello para Empresas:

Opções de implantação

O objetivo do Windows Hello para Empresas é permitir implantações para todas as organizações de qualquer porte ou cenário. Para fornecer esse tipo de implantação granular, o Windows Hello para Empresas oferece várias opções de implantação.

Modelos de implantação

É fundamentalmente importante compreender que modelo de implementação utilizar para uma implementação bem-sucedida. Alguns aspetos da implementação podem já ter sido decididos por si com base na sua infraestrutura atual.

Existem três modelos de implementação a partir dos quais pode escolher:

Modelo de implementação Descrição
🔲 Apenas na cloud Para organizações que têm apenas identidades na cloud e não acedem a recursos no local. Normalmente, estas organizações associam os respetivos dispositivos à cloud e utilizam exclusivamente recursos na cloud, como o SharePoint Online, o OneDrive e outros. Além disso, uma vez que os utilizadores não utilizam recursos no local, não precisam de certificados para VPN, porque tudo o que precisam está alojado em serviços cloud.
🔲 Híbrida Para organizações que têm identidades sincronizadas do Active Directory para Microsoft Entra ID. Estas organizações utilizam aplicações registadas no Microsoft Entra ID e querem uma experiência de início de sessão único (SSO) para recursos no local e Microsoft Entra.
🔲 Locais Para organizações que não têm identidades na cloud nem utilizam aplicações alojadas no Microsoft Entra ID. Estas organizações utilizam aplicações no local, integradas no Active Directory e querem uma experiência de utilizador de SSO ao aceder às mesmas.

Observação

  • O principal caso de utilização da implementação no local é para "Ambientes Administrativos de Segurança Avançada" também conhecidos como "Florestas Vermelhas"
  • A migração do local para a implementação híbrida requer a reimplementação

Tipos de relação de confiança

O tipo de confiança de uma implementação define como Windows Hello para Empresas clientes se autenticam no Active Directory. O tipo de fidedignidade não afeta a autenticação para Microsoft Entra ID. Por este motivo, o tipo de fidedignidade não é aplicável a um modelo de implementação apenas na cloud.

Windows Hello para Empresas autenticação para Microsoft Entra ID utiliza sempre a chave e não um certificado (excluindo a autenticação de card inteligente num ambiente federado).

O tipo de fidedignidade determina se emite certificados de autenticação para os seus utilizadores. Um modelo de confiança não é mais seguro do que o outro.

A implementação de certificados para utilizadores e controladores de domínio requer mais configuração e infraestrutura, o que também pode ser um fator a considerar na sua decisão. Mais infraestruturas necessárias para implementações de confiança de certificados incluem uma autoridade de registo de certificados. Num ambiente federado, tem de ativar a opção Repetição de Escrita de Dispositivos no Microsoft Entra Ligar.

Existem três tipos de fidedignidade a partir dos quais pode escolher:

Tipo de relação de confiança Descrição
🔲 Cloud Kerberos Os utilizadores autenticam-se no Active Directory ao pedir um TGT ao Microsoft Entra ID com Microsoft Entra Kerberos. Os controladores de domínio no local continuam a ser responsáveis pelas permissões de serviço e autorização do Kerberos. A confiança do Kerberos na Cloud utiliza a mesma infraestrutura necessária para o início de sessão da chave de segurança FIDO2 e pode ser utilizada para implementações de Windows Hello para Empresas novas ou existentes.
🔲 Chave Os utilizadores autenticam-se no Active Directory local através de uma chave vinculada ao dispositivo (hardware ou software) criada durante a experiência de aprovisionamento do Windows Hello. É necessário distribuir certificados para controladores de domínio.
🔲 Certificado O tipo de fidedignidade do certificado emite certificados de autenticação para os utilizadores. Os utilizadores autenticam-se com um certificado pedido através de uma chave vinculada ao dispositivo (hardware ou software) criada durante a experiência de aprovisionamento do Windows Hello.

A fidedignidade da chave e a fidedignidade do certificado utilizam Kerberos baseado na autenticação do certificado ao pedir permissões de concessão de permissões (TGTs) kerberos para autenticação no local. Este tipo de autenticação requer um PKI para certificados DC e requer certificados de utilizador final para a confiança do certificado.

O objetivo do Windows Hello para Empresas a confiança kerberos na cloud é proporcionar uma experiência de implementação mais simples, em comparação com os outros tipos de fidedignidade:

  • Não é necessário implementar uma infraestrutura de chaves públicas (PKI) ou alterar um PKI existente
  • Não é necessário sincronizar chaves públicas entre o Microsoft Entra ID e o Active Directory para que os utilizadores acedam aos recursos no local. Não existe nenhum atraso entre o aprovisionamento de Windows Hello para Empresas do utilizador e a capacidade de autenticação no Active Directory
  • O início de sessão da chave de segurança FIDO2 pode ser implementado com uma configuração adicional mínima

Dica

Windows Hello para Empresas confiança kerberos na cloud é o modelo de implementação recomendado em comparação com o modelo de fidedignidade da chave. Também é o modelo de implementação preferencial se não precisar de suportar cenários de autenticação de certificados.

A confiança do Kerberos na Cloud requer a implementação de Microsoft Entra Kerberos. Para obter mais informações sobre como Microsoft Entra Kerberos permite o acesso a recursos no local, veja Ativar o início de sessão da chave de segurança sem palavra-passe em recursos no local.

Requisitos de PKI

A confiança do Kerberos na Cloud é a única opção de implementação híbrida que não requer a implementação de certificados. Os outros modelos híbridos e no local dependem de uma PKI empresarial como âncora de confiança para autenticação:

  • Os controladores de domínio para implementações híbridas e no local precisam de um certificado para os dispositivos Windows confiarem no controlador de domínio como legítimo
  • As implementações que utilizam o tipo de fidedignidade do certificado requerem uma PKI empresarial e uma autoridade de registo de certificados (CRA) para emitir certificados de autenticação para os utilizadores. O AD FS é utilizado como cra
  • As implementações híbridas podem ter de emitir certificados VPN para os utilizadores ativar os recursos no local de conectividade
Modelo de implementação Tipo de relação de confiança É necessário pKI?
🔲 Apenas na cloud n/d não
🔲 Híbrida Cloud Kerberos não
🔲 Híbrida Chave sim
🔲 Híbrida Certificado sim
🔲 Locais Chave sim
🔲 Locais Certificado sim

Autenticação para Microsoft Entra ID

Os utilizadores podem autenticar-se para Microsoft Entra ID através da autenticação federada ou da autenticação na cloud (não automatizada). Os requisitos variam com base no tipo de fidedignidade:

Modelo de implementação Tipo de relação de confiança Autenticação para Microsoft Entra ID Requisitos
🔲 Apenas na cloud n/d Autenticação na cloud n/d
🔲 Apenas na cloud n/d Autenticação federada Serviço de federação não Microsoft
🔲 Híbrida Confiança do Kerberos na Cloud Autenticação na cloud Sincronização do hash de palavras-passe (PHS) ou Autenticação pass-through (PTA)
🔲 Híbrida Confiança do Kerberos na Cloud Autenticação federada AD FS ou serviço de federação não Microsoft
🔲 Híbrida Confiança de chave Autenticação na cloud Sincronização do hash de palavras-passe (PHS) ou Autenticação pass-through (PTA)
🔲 Híbrida Confiança de chave Autenticação federada AD FS ou serviço de federação não Microsoft
🔲 Híbrida Certificados confiáveis Autenticação federada Este modelo de implementação não suporta PTA ou PHS. O Active Directory tem de ser federado com Microsoft Entra ID com o AD FS

Para saber mais:

Referência técnica de registro do dispositivo

Para implementações no local, o servidor que executa a função Serviços de Federação do Active Directory (AD FS) (AD FS) é responsável pelo registo de dispositivos. Para implementações apenas na cloud e híbridas, os dispositivos têm de se registar no Microsoft Entra ID.

Modelo de implementação Tipo de associação suportado Fornecedor de serviços de registo de dispositivos
Apenas na cloud Microsoft Entra aderido
Microsoft Entra registado		 Microsoft Entra ID
Híbrida Microsoft Entra aderido
Microsoft Entra associado híbrido
Microsoft Entra registado		 Microsoft Entra ID
Locais Domínio do Active Directory associado AD FS

Importante

Para obter Microsoft Entra documentação de orientação híbrida associada, veja Planear a implementação da associação híbrida Microsoft Entra.

Autenticação multifator

O objetivo da Windows Hello para Empresas é afastar as organizações das palavras-passe ao fornecer-lhes uma credencial forte que permita uma autenticação de dois fatores fácil. A experiência de aprovisionamento incorporada aceita as credenciais fracas do utilizador (nome de utilizador e palavra-passe) como a primeira autenticação de fator. No entanto, o utilizador tem de fornecer um segundo fator de autenticação antes de o Windows aprovisionar uma credencial forte:

  • Para implementações apenas na cloud e híbridas, existem diferentes opções para a autenticação multifator, incluindo Microsoft Entra MFA
  • As implementações no local têm de utilizar uma opção multifator que possa ser integrada como um adaptador multifator do AD FS. As organizações podem escolher entre opções que não sejam da Microsoft que oferecem um adaptador MFA do AD FS. Para obter mais informações, veja Métodos de autenticação adicionais da Microsoft e não da Microsoft

Importante

A partir de 1 de julho de 2019, a Microsoft não oferece o Servidor MFA para novas implementações. As novas implementações que requerem autenticação multifator devem utilizar a autenticação multifator Microsoft Entra baseada na cloud.

A partir de 30 de setembro de 2024, as implementações do Servidor Multi-Factor Authentication do Azure deixarão de atender pedidos de MFA. Para garantir serviços de autenticação ininterruptos e permanecer num estado suportado, as organizações devem migrar os dados de autenticação dos utilizadores para a MFA do Azure baseada na cloud.

Modelo de implementação Opções de MFA
🔲 Apenas na cloud Microsoft Entra MFA
🔲 Apenas na cloud MFA não Microsoft, através do método de autenticação externa no Microsoft Entra ID ou federação
🔲 Híbrida Microsoft Entra MFA
🔲 Híbrida MFA não Microsoft, através do método de autenticação externa no Microsoft Entra ID ou federação
🔲 Locais Adaptador MFA do AD FS

Para saber mais:

MFA e autenticação federada

É possível que os domínios federados configurem o sinalizador FederatedIdpMfaBehavior . O sinalizador instrui Microsoft Entra ID a aceitar, impor ou rejeitar o desafio da MFA do IdP federado. Para obter mais informações, veja federatedIdpMfaBehavior values (Valores federatedIdpMfaBehavior). Para marcar esta definição, utilize o seguinte comando do PowerShell:

Connect-MgGraph
$DomainId = "<your federated domain name>"
Get-MgDomainFederationConfiguration -DomainId $DomainId |fl

Para rejeitar a afirmação de MFA do IdP federado, utilize o seguinte comando. Esta alteração afeta todos os cenários de MFA para o domínio federado:

Update-MgDomainFederationConfiguration -DomainId $DomainId -FederatedIdpMfaBehavior rejectMfaByFederatedIdp

Se configurar o sinalizador com um valor de acceptIfMfaDoneByFederatedIdp (predefinição) ou enforceMfaByFederatedIdp, tem de verificar se o IDP federado está corretamente configurado e a trabalhar com o adaptador MFA e o fornecedor utilizados pelo seu IdP.

Registro de chave

A experiência de aprovisionamento de Windows Hello para Empresas incorporada cria um par de chaves assimétricas vinculada ao dispositivo como credenciais do utilizador. A chave privada está protegida pelos módulos de segurança do dispositivo. A credencial é uma chave de utilizador, não uma chave de dispositivo. A experiência de aprovisionamento regista a chave pública do utilizador no fornecedor de identidade:

Modelo de implementação Fornecedor de serviços de registo de chaves
Apenas na cloud Microsoft Entra ID
Híbrida Microsoft Entra ID
Locais AD FS

Sincronização de diretório

No entanto, as implementações híbridas e no local utilizam a sincronização de diretórios, cada uma para uma finalidade diferente:

  • As implementações híbridas utilizam o Microsoft Entra Connect Sync para sincronizar identidades do Active Directory (utilizadores e dispositivos) ou credenciais entre si e Microsoft Entra ID. Durante o processo de aprovisionamento do Windows Hello para Empresas, os utilizadores registam a parte pública da respetiva credencial de Windows Hello para Empresas com Microsoft Entra ID. Microsoft Entra Connect Sync sincroniza a chave pública Windows Hello para Empresas com o Active Directory. Esta sincronização permite que o SSO Microsoft Entra ID e os respetivos componentes federados.

    Importante

    Windows Hello para Empresas está associada entre um utilizador e um dispositivo. O objeto do utilizador e do dispositivo tem de ser sincronizado entre Microsoft Entra ID e o Active Directory.

  • As implementações no local utilizam a sincronização de diretórios para importar utilizadores do Active Directory para o servidor MFA do Azure, que envia dados para o serviço cloud MFA para efetuar a verificação
Modelo de implementação Opções de sincronização de diretórios
Apenas na cloud n/d
Híbrida sincronização do Microsoft Entra Connect
Locais Servidor MFA do Azure

Importante

A partir de 30 de setembro de 2024, as implementações do Servidor Multi-Factor Authentication do Azure deixarão de atender pedidos de MFA. Para garantir serviços de autenticação ininterruptos e permanecer num estado suportado, as organizações devem migrar os dados de autenticação dos utilizadores para a MFA do Azure baseada na cloud.

Opções de configuração do dispositivo

Windows Hello para Empresas fornece um conjunto avançado de definições de política granulares. Existem duas opções de main para configurar Windows Hello para Empresas: fornecedor de serviços de configuração (CSP) e política de grupo (GPO).

  • A opção CSP é ideal para dispositivos geridos através de uma solução de Gerenciamento de Dispositivos Móvel (MDM), como Microsoft Intune. Os CSPs também podem ser configurados com pacotes de aprovisionamento
  • O GPO pode ser utilizado para configurar dispositivos associados a um domínio e onde os dispositivos não são geridos através da MDM
Modelo de implementação Opções de configuração do dispositivo
🔲 Apenas na cloud CSP
🔲 Apenas na cloud GPO (local)
🔲 Híbrida CSP
🔲 Híbrida GPO (Active Directory ou local)
🔲 Locais CSP
🔲 Locais GPO (Active Directory ou local)

Licenciamento para requisitos de serviços cloud

Seguem-se algumas considerações sobre os requisitos de licenciamento dos serviços cloud:

  • Windows Hello para Empresas não requer uma subscrição P1 ou P2 Microsoft Entra ID. No entanto, algumas dependências, como a inscrição automática mdm e o Acesso Condicional , fazem
    • Os dispositivos geridos através de MDM não necessitam de uma subscrição P1 ou P2 Microsoft Entra ID. Ao renunciarem à subscrição, os utilizadores têm de inscrever manualmente dispositivos na solução de MDM, como Microsoft Intune ou uma MDM não Microsoft suportada
  • Pode implementar Windows Hello para Empresas com o escalão Gratuito Microsoft Entra ID. Todas as contas Microsoft Entra ID Gratuitas podem utilizar Microsoft Entra autenticação multifator para as funcionalidades sem palavra-passe do Windows
  • A inscrição de um certificado através da autoridade de registo do AD FS requer que os dispositivos se autentiquem no servidor do AD FS, o que requer a repetição de escrita do dispositivo, uma funcionalidade Microsoft Entra ID P1 ou P2
Modelo de implementação Tipo de relação de confiança Licenças de serviços cloud (mínimo)
🔲 Apenas na cloud n/d não necessário
🔲 Híbrida Cloud Kerberos não necessário
🔲 Híbrida Chave não necessário
🔲 Híbrida Certificado Microsoft Entra ID P1
🔲 Locais Chave MFA do Azure, se utilizado como solução de MFA
🔲 Locais Certificado MFA do Azure, se utilizado como solução de MFA

Importante

A partir de 30 de setembro de 2024, as implementações do Servidor Multi-Factor Authentication do Azure deixarão de atender pedidos de MFA. Para garantir serviços de autenticação ininterruptos e permanecer num estado suportado, as organizações devem migrar os dados de autenticação dos utilizadores para a MFA do Azure baseada na cloud.

Requisitos do Sistema Operativo

Requisitos do Windows

Todas as versões suportadas do Windows podem ser utilizadas com Windows Hello para Empresas. No entanto, a confiança do Kerberos na cloud requer versões mínimas:

Modelo de implementação Tipo de relação de confiança Versão do Windows
🔲 Apenas na cloud n/d Todas as versões suportadas
🔲 Híbrida Cloud Kerberos - Windows 10 21H2, com KB5010415 e posterior
- Windows 11 21H2, com KB5010414 e posterior
🔲 Híbrida Chave Todas as versões suportadas
🔲 Híbrida Certificado Todas as versões suportadas
🔲 Locais Chave Todas as versões suportadas
🔲 Locais Certificado Todas as versões suportadas

Requisitos do Windows Server

Windows Hello para Empresas pode ser utilizado para autenticar em todas as versões suportadas do Windows Server como um controlador de domínio. No entanto, a confiança do Kerberos na cloud requer versões mínimas:

Modelo de implementação Tipo de relação de confiança Versão do SO do controlador de domínio
🔲 Apenas na cloud n/d Todas as versões suportadas
🔲 Híbrida Cloud Kerberos - Windows Server 2016, com KB3534307 e posterior
- Windows Server 2019, com KB4534321 e posterior
- Windows Server 2022
- Windows Server 2025
🔲 Híbrida Chave Todas as versões suportadas
🔲 Híbrida Certificado Todas as versões suportadas
🔲 Locais Chave Todas as versões suportadas
🔲 Locais Certificado Todas as versões suportadas

Os níveis funcionais de floresta e funcionais de domínio mínimos necessários são o Windows Server 2008 R2 para todos os modelos de implementação.

Preparar utilizadores

Quando estiver pronto para ativar Windows Hello para Empresas na sua organização, certifique-se de que prepara os utilizadores ao explicar como aprovisionar e utilizar Windows Hello.

Para saber mais, veja Preparar utilizadores.

Próximas etapas

Agora que leu sobre as diferentes opções e requisitos de implementação, pode escolher a implementação mais adequada à sua organização.

Para saber mais sobre o processo de implementação, escolha um modelo de implementação e um tipo de confiança nas seguintes listas pendentes: