Planear uma implementação do 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 do 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 o 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 o 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 sua 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 para a implementação do Windows Hello para Empresas.
Existem sete áreas principais a considerar ao planear uma implementação do 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 com identidades sincronizadas do Active Directory com o 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 os recursos no local e do Microsoft Entra. |
| 🔲 | Locais | Para organizações que não têm identidades na cloud ou 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 a forma como os clientes do Windows Hello para Empresas se autenticam no Active Directory. O tipo de fidedignidade não afeta a autenticação no ID do Microsoft Entra. Por este motivo, o tipo de fidedignidade não é aplicável a um modelo de implementação apenas na cloud.
A autenticação do Windows Hello para Empresas no Microsoft Entra ID utiliza sempre a chave e não um certificado (excluindo a autenticação de smart card 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 Connect.
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 ID do Microsoft Entra através do 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 novas ou existentes do Windows Hello para Empresas. |
| 🔲 | Chave | Os utilizadores autenticam-se no Active Directory no local com 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 através de 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 da confiança kerberos na cloud do Windows Hello para Empresas é 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 a recursos no local. Não existe nenhum atraso entre o aprovisionamento do 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
A confiança kerberos na cloud do Windows Hello para Empresas é o modelo de implementação recomendado em comparação com o modelo de fidedignidade 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 Cloud Kerberos requer a implementação do Microsoft Entra Kerberos. Para obter mais informações sobre como o 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 nos 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 no Microsoft Entra ID
Os utilizadores podem autenticar-se no Microsoft Entra ID através da autenticação federada ou da autenticação na cloud (sem autenticação). Os requisitos variam com base no tipo de fidedignidade:
| Modelo de implementação | Tipo de relação de confiança | Autenticação no 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 o Microsoft Entra ID com o AD FS |
Para saber mais:
- Federação com o ID do Microsoft Entra
- Sincronização do hash de palavras-passe (PHS)
- Autenticação pass-through (PTA)
Referência técnica de registro do dispositivo
Para implementações no local, o servidor que executa a função dos Serviços de Federação do Active Directory (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 aderiu Microsoft Entra registado |
Microsoft Entra ID |
| Híbrida | Microsoft Entra aderiu Microsoft Entra híbrido associado Microsoft Entra registado |
Microsoft Entra ID |
| Locais | Domínio do Active Directory associado | AD FS |
Importante
Para obter orientações sobre a associação híbrida do Microsoft Entra , veja Planear a implementação da associação híbrida do Microsoft Entra.
Autenticação multifator
O objetivo do 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 o 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 do 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:
- Configurar as definições de autenticação multifator do Microsoft Entra
- Gerir um método de autenticação externo no Microsoft Entra ID
MFA e autenticação federada
É possível que os domínios federados configurem o sinalizador FederatedIdpMfaBehavior . O sinalizador indica ao Microsoft Entra ID para aceitar, impor ou rejeitar o desafio da MFA do IdP federado. Para obter mais informações, veja federatedIdpMfaBehavior values (Valores federatedIdpMfaBehavior). Para verificar 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 incorporada do Windows Hello para Empresas 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 o Microsoft Entra ID. Durante o processo de aprovisionamento do Windows Hello para Empresas, os utilizadores registam a parte pública das credenciais do Windows Hello para Empresas com o Microsoft Entra ID. O Microsoft Entra Connect Sync sincroniza a chave pública do Windows Hello para Empresas com o Active Directory. Esta sincronização permite o SSO para o Microsoft Entra ID e os respetivos componentes federados.
Importante
O Windows Hello para Empresas está ligado entre um utilizador e um dispositivo. O objeto do utilizador e do dispositivo tem de ser sincronizado entre o 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
O Windows Hello para Empresas fornece um conjunto avançado de definições de política granulares. Existem duas opções principais para configurar o 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 Gestão de Dispositivos Móveis (MDM), como o 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:
- O Windows Hello para Empresas não necessita de uma subscrição do Microsoft Entra ID P1 ou P2. 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 do Microsoft Entra ID P1 ou P2. Ao renunciarem à subscrição, os utilizadores têm de inscrever manualmente dispositivos na solução de MDM, como o Microsoft Intune ou um MDM não Microsoft suportado
- Pode implementar o Windows Hello para Empresas com o escalão Gratuito do Microsoft Entra ID. Todas as contas Gratuitas do Microsoft Entra ID podem utilizar a autenticação multifator do Microsoft Entra para as funcionalidades sem palavra-passe do Windows
- Algumas funcionalidades de autenticação multifator do Microsoft Entra necessitam de uma licença. Para obter mais informações, veja Funcionalidades e licenças da autenticação multifator do Microsoft Entra.
- 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 do 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 o 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
Todas as versões suportadas do Windows Server podem ser utilizadas com o Windows Hello para Empresas como 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 |
| 🔲 | 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 |
Preparar utilizadores
Quando estiver pronto para ativar o Windows Hello para Empresas na sua organização, certifique-se de que prepara os utilizadores ao explicar como aprovisionar e utilizar o 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:
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários