Planejar uma implantaçã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 você tiver um locatário Microsoft Entra ID, poderá usar nosso assistente online e interativo sem senha que percorre as mesmas opções em vez de usar nosso guia manual abaixo. O Assistente sem Senha está disponível no Centro de administração do Microsoft 365.
Uso do guia
Há muitas opções disponíveis para implantar Windows Hello para Empresas, garantindo compatibilidade com várias infraestruturas organizacionais. Embora o processo de implantação possa parecer complexo, a maioria das organizações descobrirá que já implementou a infraestrutura necessária. É importante observar que Windows Hello para Empresas é um sistema distribuído e requer um planejamento adequado entre várias equipes dentro de uma organização.
Este guia visa simplificar o processo de implantação ajudando você a tomar decisões informadas sobre cada aspecto de sua implantação Windows Hello para Empresas. Ele fornece informações sobre as opções disponíveis e auxilia na seleção da abordagem de implantação que melhor se adequa ao seu ambiente.
Como proceder
Leia este documento e registre suas decisões. Quando terminar, você deve ter todas as informações necessárias para avaliar as opções disponíveis e determinar os requisitos para sua implantação Windows Hello para Empresas.
Há sete main áreas a considerar ao planejar uma implantação de 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 entender qual modelo de implantação usar para uma implantação bem-sucedida. Alguns aspectos da implantação podem já ter sido decididos para você com base na infraestrutura atual.
Há três modelos de implantação dos quais você pode escolher:
Modelo de implantação | Descrição | |
---|---|---|
🔲 | Somente nuvem | Para organizações que têm apenas identidades de nuvem e não acessam recursos locais. Normalmente, essas organizações juntam seus dispositivos à nuvem e usam exclusivamente recursos na nuvem, como SharePoint Online, OneDrive e outros. Além disso, como os usuários não usam recursos locais, eles não precisam de certificados para coisas como VPN porque tudo o que precisam está hospedado nos serviços de nuvem. |
🔲 | Híbrida | Para organizações que têm identidades sincronizadas do Active Directory para Microsoft Entra ID. Essas organizações usam aplicativos registrados em Microsoft Entra ID e querem uma experiência de SSO (logon único) para recursos locais e Microsoft Entra. |
🔲 | Locais | Para organizações que não têm identidades de nuvem ou usam aplicativos hospedados em Microsoft Entra ID. Essas organizações usam aplicativos locais, integrados ao Active Directory e querem experiências de usuário do SSO ao acessá-los. |
Observação
- O principal caso de uso da implantação local é para "Ambientes Administrativos de Segurança Aprimorados" também conhecidos como "Florestas Vermelhas"
- Migração de implantação local para híbrida requer reimplantação
Tipos de relação de confiança
O tipo de confiança de uma implantação define como Windows Hello para Empresas clientes se autenticam no Active Directory. O tipo de confiança não afeta a autenticação para Microsoft Entra ID. Por esse motivo, o tipo de confiança não é aplicável a um modelo de implantação somente na nuvem.
Windows Hello para Empresas autenticação para Microsoft Entra ID sempre usa a chave, não um certificado (excluindo a autenticação de cartão inteligente em um ambiente federado).
O tipo de confiança determina se você emite certificados de autenticação para seus usuários. Um modelo de confiança não é mais seguro que o outro.
A implantação de certificados para usuários e controladores de domínio requer mais configuração e infraestrutura, o que também pode ser um fator a ser considerado em sua decisão. Mais infraestrutura necessária para implantações de confiança de certificado inclui uma autoridade de registro de certificado. Em um ambiente federado, você deve ativar a opção Writeback do Dispositivo no Microsoft Entra Conectar.
Há três tipos de confiança dos quais você pode escolher:
Tipo de relação de confiança | Descrição | |
---|---|---|
🔲 | Kerberos de Nuvem | Os usuários se autenticam no Active Directory solicitando um TGT de Microsoft Entra ID, usando Microsoft Entra Kerberos. Os controladores de domínio locais ainda são responsáveis pelos tíquetes de serviço kerberos e pela autorização. A confiança do Kerberos na Nuvem usa a mesma infraestrutura necessária para a entrada da chave de segurança FIDO2 e pode ser usada para implantações de Windows Hello para Empresas novas ou existentes. |
🔲 | Chave | Os usuários se autenticam no Active Directory local usando uma chave vinculada ao dispositivo (hardware ou software) criada durante a experiência de provisionamento Windows Hello. Ele requer distribuir certificados para controladores de domínio. |
🔲 | Certificado | O tipo de confiança de certificado emite certificados de autenticação para os usuários. Os usuários autenticam usando um certificado solicitado usando uma chave vinculada ao dispositivo (hardware ou software) criada durante o Windows Hello experiência de provisionamento. |
Confiança de chave e confiança de certificado usam Kerberos baseado em autenticação de certificado ao solicitar TGTs (kerberos ticket-granting-tickets) para autenticação local. Esse tipo de autenticação requer um PKI para certificados DC e requer certificados de usuário final para a confiança do certificado.
O objetivo de Windows Hello para Empresas confiança kerberos na nuvem é fornecer uma experiência de implantação mais simples, quando comparada com os outros tipos de confiança:
- Não é necessário implantar uma PKI (infraestrutura de chave pública) ou alterar um PKI existente
- Não é necessário sincronizar chaves públicas entre Microsoft Entra ID e o Active Directory para que os usuários acessem recursos locais. Não há nenhum atraso entre o provisionamento de Windows Hello para Empresas do usuário e a autenticação no Active Directory
- A entrada da chave de segurança FIDO2 pode ser implantada com configuração extra mínima
Dica
Windows Hello para Empresas confiança kerberos na nuvem é o modelo de implantação recomendado quando comparado ao modelo de confiança chave. Ele também é o modelo de implantação preferencial se você não precisar dar suporte a cenários de autenticação de certificado.
A confiança do Kerberos na nuvem requer a implantação do Microsoft Entra Kerberos. Para obter mais informações sobre como Microsoft Entra Kerberos habilita o acesso a recursos locais, confira habilitando a entrada de chave de segurança sem senha para recursos locais.
Requisitos PKI
A confiança do Kerberos na nuvem é a única opção de implantação híbrida que não exige a implantação de nenhum certificado. Os outros modelos híbridos e locais dependem de um PKI empresarial como uma âncora de confiança para autenticação:
- Os controladores de domínio para implantações híbridas e locais precisam de um certificado para dispositivos Windows confiarem no controlador de domínio como legítimo
- As implantações que usam o tipo de confiança de certificado exigem uma PKI corporativa e uma AUTORIDADE de registro de certificado (CRA) para emitir certificados de autenticação aos usuários. O AD FS é usado como UM CRA
- As implantações híbridas podem precisar emitir certificados VPN aos usuários para habilitar recursos locais de conectividade
Modelo de implantação | Tipo de relação de confiança | PKI necessário? | |
---|---|---|---|
🔲 | Somente nuvem | n/d | não |
🔲 | Híbrida | Kerberos de Nuvem | não |
🔲 | Híbrida | Chave | sim |
🔲 | Híbrida | Certificado | sim |
🔲 | Locais | Chave | sim |
🔲 | Locais | Certificado | sim |
Autenticação para Microsoft Entra ID
Os usuários podem se autenticar para Microsoft Entra ID usando autenticação federada ou autenticação de nuvem (não inserida). Os requisitos variam de acordo com o tipo de confiança:
Modelo de implantação | Tipo de relação de confiança | Autenticação para Microsoft Entra ID | Requisitos | |
---|---|---|---|---|
🔲 | Somente nuvem | n/d | Autenticação na nuvem | n/d |
🔲 | Somente nuvem | n/d | Autenticação federada | Serviço de federação que não é da Microsoft |
🔲 | Híbrida | Confiança do Cloud Kerberos | Autenticação na nuvem | PHS (sincronização de hash de senha) ou autenticação de passagem (PTA) |
🔲 | Híbrida | Confiança do Cloud Kerberos | Autenticação federada | AD FS ou serviço de federação que não é da Microsoft |
🔲 | Híbrida | Confiança de chave | Autenticação na nuvem | PHS (sincronização de hash de senha) ou autenticação de passagem (PTA) |
🔲 | Híbrida | Confiança de chave | Autenticação federada | AD FS ou serviço de federação que não é da Microsoft |
🔲 | Híbrida | Certificados confiáveis | Autenticação federada | Esse modelo de implantação não dá suporte a PTA ou PHS. O Active Directory deve ser federado com Microsoft Entra ID usando o AD FS |
Para saber mais:
- Federação com Microsoft Entra ID
- Sincronização de hash de senha (PHS)
- Autenticação de passagem (PTA)
Referência técnica de registro do dispositivo
Para implantações locais, o servidor que executa a função Serviços de Federação do Active Directory (AD FS) (AD FS) é responsável pelo registro do dispositivo. Para implantações híbridas e somente na nuvem, os dispositivos devem se registrar em Microsoft Entra ID.
Modelo de implantação | Tipo de junção com suporte | Provedor de serviços de registro de dispositivo |
---|---|---|
Somente nuvem | Microsoft Entra ingressado Microsoft Entra registrado |
Microsoft Entra ID |
Híbrida | Microsoft Entra ingressado Microsoft Entra híbrido ingressado Microsoft Entra registrado |
Microsoft Entra ID |
Locais | Domínio do Active Directory ingressado | AD FS |
Importante
Para Microsoft Entra diretrizes de junção híbrida, examine Planejar sua implementação de junção híbrida Microsoft Entra.
Autenticação multifator
O objetivo do Windows Hello para Empresas é afastar as organizações das senhas fornecendo-lhes uma credencial forte que permita a autenticação fácil de dois fatores. A experiência de provisionamento interno aceita as credenciais fracas do usuário (nome de usuário e senha) como a autenticação do primeiro fator. No entanto, o usuário deve fornecer um segundo fator de autenticação antes que o Windows provisione uma credencial forte:
- Para implantações híbridas e somente na nuvem, há opções diferentes para autenticação multifator, incluindo Microsoft Entra MFA
- As implantações locais devem usar uma opção multifator que pode se integrar como um adaptador multifator do AD FS. As organizações podem escolher entre opções que não são da Microsoft que oferecem um adaptador MFA do AD FS. Para obter mais informações, confira 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 MFA Server para novas implantações. Novas implantações que exigem autenticação multifator devem usar a autenticação multifator baseada em nuvem Microsoft Entra. A implantação existente em que o Servidor MFA foi ativado antes de 1º de julho de 2019 pode baixar a versão mais recente, atualizações futuras e gerar credenciais de ativação. Para obter mais informações, consulte Introdução ao Servidor de Autenticação Multifator do Azure.
Modelo de implantação | Opções MFA | |
---|---|---|
🔲 | Somente nuvem | Microsoft Entra MFA |
🔲 | Somente nuvem | MFA não Microsoft por meio de Microsoft Entra ID controles personalizados ou federação |
🔲 | Híbrida | Microsoft Entra MFA |
🔲 | Híbrida | MFA não Microsoft por meio de Microsoft Entra ID controles personalizados ou federação |
🔲 | Locais | Adaptador MFA do AD FS |
Para obter mais informações sobre como configurar Microsoft Entra autenticação multifator, consulte Configurar Microsoft Entra configurações de autenticação multifator.
Para obter mais informações sobre como configurar o AD FS para fornecer autenticação multifator, consulte Configurar o Azure MFA como provedor de autenticação com o AD FS.
MFA e autenticação federada
É possível que domínios federados configurem o sinalizador FederatedIdpMfaBehavior . O sinalizador instrui Microsoft Entra ID a aceitar, impor ou rejeitar o desafio MFA do IdP federado. Para obter mais informações, confira valores federatedIdpMfaBehavior. Para marcar essa configuração, use o seguinte comando do PowerShell:
Connect-MgGraph
$DomainId = "<your federated domain name>"
Get-MgDomainFederationConfiguration -DomainId $DomainId |fl
Para rejeitar a declaração MFA do IdP federado, use o comando a seguir. Essa alteração afeta todos os cenários de MFA para o domínio federado:
Update-MgDomainFederationConfiguration -DomainId $DomainId -FederatedIdpMfaBehavior rejectMfaByFederatedIdp
Se você configurar o sinalizador com um valor de acceptIfMfaDoneByFederatedIdp
(padrão) ou enforceMfaByFederatedIdp
, deverá verificar se o IDP federado está configurado corretamente e trabalhando com o adaptador e o provedor MFA usados pelo IdP.
Registro de chave
A experiência interna de provisionamento de Windows Hello para Empresas cria um par de chaves assimétricas vinculados ao dispositivo como as credenciais do usuário. A chave privada é protegida pelos módulos de segurança do dispositivo. A credencial é uma chave de usuário, não uma chave de dispositivo. A experiência de provisionamento registra a chave pública do usuário com o provedor de identidade:
Modelo de implantação | Provedor de serviços de registro de chave |
---|---|
Somente nuvem | Microsoft Entra ID |
Híbrida | Microsoft Entra ID |
Locais | AD FS |
Sincronização de diretório
As implantações híbridas e locais usam a sincronização de diretório, no entanto, cada uma para uma finalidade diferente:
- As implantações híbridas usam Microsoft Entra Conectar Sincronização para sincronizar identidades do Active Directory (usuários e dispositivos) ou credenciais entre si e Microsoft Entra ID. Durante o processo de provisionamento do Windows Hello for Business, os usuários registram a parte pública de sua credencial Windows Hello para Empresas com Microsoft Entra ID. Microsoft Entra o Connect Sync sincroniza a chave pública Windows Hello para Empresas para o Active Directory. Essa sincronização permite que o SSO Microsoft Entra ID e seus componentes federados.
Importante
Windows Hello para Empresas está vinculado entre um usuário e um dispositivo. O objeto usuário e o dispositivo devem ser sincronizados entre Microsoft Entra ID e o Active Directory.
- Implantações locais usam a sincronização de diretório para importar usuários do Active Directory para o servidor MFA do Azure, que envia dados para o serviço de nuvem MFA para executar a verificação
Modelo de implantação | Opções de sincronização de diretório |
---|---|
Somente nuvem | n/d |
Híbrida | Microsoft Entra Conectar Sincronização |
Locais | Servidor MFA do Azure |
Opções de configuração do dispositivo
Windows Hello para Empresas fornece um conjunto avançado de configurações de política granular. Há duas opções main para configurar Windows Hello para Empresas: CSP (provedor de serviços de configuração) e GPO (política de grupo).
- A opção CSP é ideal para dispositivos gerenciados por meio de uma solução MDM (Mobile Gerenciamento de Dispositivos), como Microsoft Intune. CSPs também podem ser configurados com pacotes de provisionamento
- O GPO pode ser usado para configurar dispositivos ingressados no domínio e onde os dispositivos não são gerenciados por meio do MDM
Modelo de implantação | Opções de configuração do dispositivo | |
---|---|---|
🔲 | Somente nuvem | CSP |
🔲 | Somente nuvem | 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 de nuvem
Aqui estão algumas considerações sobre os requisitos de licenciamento para serviços de nuvem:
- Windows Hello para Empresas não requer uma assinatura P1 ou P2 Microsoft Entra ID. No entanto, algumas dependências, como o registro automático do MDM e o Acesso Condicional fazem
- Os dispositivos gerenciados por meio do MDM não exigem uma assinatura P1 ou P2 Microsoft Entra ID. Ao abandonar a assinatura, os usuários devem registrar manualmente dispositivos na solução MDM, como Microsoft Intune ou um MDM não Microsoft com suporte
- Você pode implantar Windows Hello para Empresas usando a camada Microsoft Entra ID Free. Todas as contas gratuitas Microsoft Entra ID podem usar Microsoft Entra autenticação multifator para os recursos sem senha do Windows
- Alguns Microsoft Entra recursos de autenticação multifator exigem uma licença. Para obter mais informações, consulte Recursos e licenças para Microsoft Entra autenticação multifator.
- Registrar um certificado usando a autoridade de registro do AD FS requer que os dispositivos se autentiquem no servidor AD FS, o que requer gravação de dispositivo, um recurso P1 ou P2 Microsoft Entra ID
Modelo de implantação | Tipo de relação de confiança | Licenças de serviços de nuvem (mínimo) | |
---|---|---|---|
🔲 | Somente nuvem | n/d | não necessário |
🔲 | Híbrida | Kerberos de Nuvem | não necessário |
🔲 | Híbrida | Chave | não necessário |
🔲 | Híbrida | Certificado | Microsoft Entra ID P1 |
🔲 | Locais | Chave | Azure MFA, se usado como solução MFA |
🔲 | Locais | Certificado | Azure MFA, se usado como solução MFA |
Requisitos do Sistema Operacional
Requisitos do Windows
Todas as versões do Windows com suporte podem ser usadas com Windows Hello para Empresas. No entanto, a confiança kerberos na nuvem requer versões mínimas:
Modelo de implantação | Tipo de relação de confiança | Versão do Windows | |
---|---|---|---|
🔲 | Somente nuvem | n/d | Todas as versões com suporte |
🔲 | Híbrida | Kerberos de Nuvem | - Windows 10 21H2, com KB5010415 e posterior - Windows 11 21H2, com KB5010414 e posterior |
🔲 | Híbrida | Chave | Todas as versões com suporte |
🔲 | Híbrida | Certificado | Todas as versões com suporte |
🔲 | Locais | Chave | Todas as versões com suporte |
🔲 | Locais | Certificado | Todas as versões com suporte |
Requisitos do Windows Server
Todas as versões do Windows Server com suporte podem ser usadas com Windows Hello para Empresas como Controlador de Domínio. No entanto, a confiança kerberos na nuvem requer versões mínimas:
Modelo de implantação | Tipo de relação de confiança | Versão do sistema operacional do Controlador de Domínio | |
---|---|---|---|
🔲 | Somente nuvem | n/d | Todas as versões com suporte |
🔲 | Híbrida | Kerberos de Nuvem | - Windows Server 2016, com KB3534307 e posterior – Windows Server 2019, com KB4534321 e posterior – Windows Server 2022 |
🔲 | Híbrida | Chave | Todas as versões com suporte |
🔲 | Híbrida | Certificado | Todas as versões com suporte |
🔲 | Locais | Chave | Todas as versões com suporte |
🔲 | Locais | Certificado | Todas as versões com suporte |
Preparar usuários
Quando estiver pronto para habilitar Windows Hello para Empresas em sua organização, prepare os usuários explicando como provisionar e usar Windows Hello.
Para saber mais, confira Preparar usuários.
Próximas etapas
Agora que você leu sobre as diferentes opções e requisitos de implantação, você pode escolher a implementação que melhor se adequa à sua organização.
Para saber mais sobre o processo de implantação, escolha um modelo de implantação e um tipo de confiança nas seguintes listas suspensas:
Comentários
https://aka.ms/ContentUserFeedback.
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:Submeter e ver comentários