autenticação Windows Hello para Empresas
Windows Hello para Empresas autenticação é uma autenticação de dois fatores sem senha. A autenticação com Windows Hello para Empresas fornece uma experiência de entrada conveniente que autentica o usuário para recursos do Microsoft Entra ID e do Active Directory.
Microsoft Entra dispositivos ingressados se autenticam em Microsoft Entra ID durante a entrada e podem, opcionalmente, autenticar-se no Active Directory. Microsoft Entra dispositivos híbridos ingressados autenticam-se no Active Directory durante a entrada e autenticam-se para Microsoft Entra ID em segundo plano.
Microsoft Entra autenticação de junção ao Microsoft Entra ID
Observação
Todos os dispositivos ingressados Microsoft Entra autenticam com Windows Hello para Empresas para Microsoft Entra ID da mesma maneira. O tipo de confiança Windows Hello para Empresas afeta apenas como o dispositivo se autentica no AD local.
| Fase | Descrição |
|---|---|
| A | A autenticação começa quando o usuário descarta a tela de bloqueio, que dispara o Winlogon para mostrar o provedor de credencial Windows Hello para Empresas. O usuário fornece seu gesto de Windows Hello (PIN ou biometria). O provedor de credencial empacota essas credenciais e as retorna ao Winlogon. Winlogon passa as credenciais coletadas para lsass. O Lsass passa as credenciais coletadas para o provedor de suporte à segurança de Autenticação na Nuvem, conhecido como o provedor de AP de nuvem. |
| B | O provedor de AP na nuvem solicita um nó de Microsoft Entra ID. Microsoft Entra ID retorna um nó. O provedor de AP de nuvem assina o nó usando a chave privada do usuário e retorna a nonce assinada para o Microsoft Entra ID. |
| C | Microsoft Entra ID valida a nonce assinada usando a chave pública registrada com segurança do usuário na assinatura de nonce. Microsoft Entra ID valida o nó assinado retornado e cria um PRT com chave de sessão criptografada para a chave de transporte do dispositivo e retorna-a para o provedor de AP de nuvem. |
| D | O provedor de AP de nuvem recebe o PRT criptografado com chave de sessão. Usando a chave de transporte privado do dispositivo, o provedor de CLOUD AP descriptografou a chave da sessão e protege a chave da sessão usando o TPM do dispositivo. |
| E | O provedor de AP de nuvem retorna uma resposta de autenticação bem-sucedida ao lsass. O Lsass armazena em cache o PRT e informa o Winlogon sobre a autenticação de sucesso. O Winlogon cria uma sessão de logon, carrega o perfil do usuário e inicia explorer.exe. |
Microsoft Entra autenticação de junção ao Active Directory usando a confiança kerberos na nuvem
| Fase | Descrição |
|---|---|
| A | A autenticação no Active Directory de um dispositivo ingressado Microsoft Entra começa com as primeiras tentativas do usuário de usar um recurso que precisa da autenticação Kerberos. O provedor de suporte à segurança Kerberos, hospedado em lsass, usa metadados da chave Windows Hello para Empresas para obter uma dica do domínio do usuário. Usando a dica, o provedor usa o serviço DClocator para localizar um controlador de domínio. |
| B | Depois de localizar um controlador de domínio, o provedor Kerberos envia um TGT parcial que recebeu de Microsoft Entra ID de uma autenticação Microsoft Entra anterior para o controlador de domínio. O TGT parcial contém apenas o SID do usuário e é assinado por Microsoft Entra Kerberos. O controlador de domínio verifica se o TGT parcial é válido. Com êxito, o KDC retorna um TGT para o cliente. |
Microsoft Entra autenticação de junção ao Active Directory usando uma chave
| Fase | Descrição |
|---|---|
| A | A autenticação no Active Directory de um dispositivo ingressado Microsoft Entra começa com as primeiras tentativas do usuário de usar um recurso que precisa da autenticação Kerberos. O provedor de suporte à segurança Kerberos, hospedado em lsass, usa metadados da chave Windows Hello para Empresas para obter uma dica do domínio do usuário. Usando a dica, o provedor usa o serviço DClocator para localizar um controlador de domínio. Depois que o provedor localiza um controlador de domínio, o provedor usa a chave privada para assinar os dados de pré-autenticação kerberos. |
| B | O provedor Kerberos envia os dados de pré-autenticação assinados e sua chave pública (na forma de um certificado autoassinado) para o serviço KDC (Key Distribution Center) em execução no controlador de domínio na forma de um KERB_AS_REQ. O controlador de domínio determina que o certificado é um certificado autoassinado. Ele recupera a chave pública do certificado incluído no KERB_AS_REQ e pesquisa a chave pública no Active Directory. Ele valida o UPN para solicitação de autenticação corresponde ao UPN registrado no Active Directory e valida os dados de pré-autenticação assinados usando a chave pública do Active Directory. Com êxito, o KDC retorna um TGT para o cliente com seu certificado em um KERB_AS_REP. |
| C | O provedor Kerberos garante que pode confiar na resposta do controlador de domínio. Primeiro, ele garante as cadeias de certificados KDC para um certificado raiz confiável pelo dispositivo. Em seguida, ele garante que o certificado esteja dentro de seu período de validade e que ele não tenha sido revogado. Em seguida, o provedor Kerberos verifica se o certificado tem a Autenticação KDC presente e que o nome alternativo do assunto listado no certificado do KDC corresponde ao nome de domínio ao qual o usuário está autenticando. Depois de passar esse critério, Kerberos retorna o TGT para lsass, onde é armazenado em cache e usado para solicitações de tíquetes de serviço subsequentes. |
Observação
Você pode ter um domínio local federado com Microsoft Entra ID. Depois de provisionar com êxito Windows Hello para Empresas PIN/Bio no dispositivo ingressado Microsoft Entra, qualquer logon futuro de Windows Hello para Empresas (PIN/Bio) será autenticado diretamente em Microsoft Entra ID para obter PRT e disparar autenticação em seu DC (se LOS para DC estiver disponível) para obter Kerberos. Ele não usa mais o AD FS para autenticar para Windows Hello para Empresas entradas.
Microsoft Entra autenticação de junção ao Active Directory usando um certificado
| Fase | Descrição |
|---|---|
| A | A autenticação no Active Directory de um dispositivo ingressado Microsoft Entra começa com as primeiras tentativas do usuário de usar um recurso que precisa da autenticação Kerberos. O provedor de suporte à segurança Kerberos, hospedado em lsass, usa informações do certificado para obter uma dica do domínio do usuário. Kerberos pode usar o nome diferenciado do usuário encontrado na entidade do certificado ou pode usar o nome de entidade de usuário do usuário encontrado no nome alternativo do certificado. Usando a dica, o provedor usa o serviço DClocator para localizar um controlador de domínio. Depois que o provedor localiza um controlador de domínio ativo, o provedor usa a chave privada para assinar os dados de pré-autenticação kerberos. |
| B | O provedor Kerberos envia os dados de pré-autenticação assinados e o certificado do usuário, que inclui a chave pública, para o serviço KDC (Key Distribution Center) em execução no controlador de domínio na forma de um KERB_AS_REQ. O controlador de domínio determina que o certificado não é certificado autoassinado. O controlador de domínio garante que as cadeias de certificados para o certificado raiz confiável, estejam dentro de seu período de validade, possam ser usadas para autenticação e não foram revogadas. Ele recupera a chave pública e o UPN do certificado incluído no KERB_AS_REQ e pesquisa o UPN no Active Directory. Ele valida os dados de pré-autenticação assinados usando a chave pública do certificado. Com êxito, o KDC retorna um TGT para o cliente com seu certificado em um KERB_AS_REP. |
| C | O provedor Kerberos garante que pode confiar na resposta do controlador de domínio. Primeiro, ele garante as cadeias de certificados KDC para um certificado raiz confiável pelo dispositivo. Em seguida, ele garante que o certificado esteja dentro de seu período de validade e que ele não tenha sido revogado. Em seguida, o provedor Kerberos verifica se o certificado tem a Autenticação KDC presente e que o nome alternativo do assunto listado no certificado do KDC corresponde ao nome de domínio ao qual o usuário está autenticando. Depois de passar esse critério, Kerberos retorna o TGT para lsass, onde é armazenado em cache e usado para solicitações de tíquetes de serviço subsequentes. |
Observação
Você pode ter um domínio local federado com Microsoft Entra ID. Depois de provisionar com êxito Windows Hello para Empresas PIN/Bio ativado, qualquer logon futuro do Windows Hello para Empresas (PIN/Bio) será autenticado diretamente no Microsoft Entra ID para obter PRT, bem como autenticar em seu DC (se LOS para DC estiver disponível) para obter Kerberos como mencionado anteriormente. A federação do AD FS é usada somente quando as chamadas do Enterprise PRT são feitas do cliente. Você precisa ter o write-back do dispositivo habilitado para obter "Enterprise PRT" de sua federação.
Microsoft Entra autenticação de junção híbrida usando a confiança kerberos na nuvem
| Fase | Descrição |
|---|---|
| A | A autenticação começa quando o usuário descarta a tela de bloqueio, que dispara o Winlogon para mostrar o provedor de credencial Windows Hello para Empresas. O usuário fornece seu gesto de Windows Hello (PIN ou biometria). O provedor de credencial empacota essas credenciais e as retorna ao Winlogon. Winlogon passa as credenciais coletadas para lsass. O Lsass consulta Windows Hello para Empresas política para marcar se a confiança kerberos na nuvem estiver habilitada. Se a confiança kerberos de nuvem estiver habilitada, o Lsass passará as credenciais coletadas para o provedor de suporte de segurança de Autenticação na Nuvem ou a AP de Nuvem. A CLOUD AP solicita um nó de Microsoft Entra ID. Microsoft Entra ID retorna um nó. |
| B | A CLOUD AP assina o nó usando a chave privada do usuário e retorna o nó assinado para Microsoft Entra ID. |
| C | Microsoft Entra ID valida a nonce assinada usando a chave pública registrada com segurança do usuário na assinatura de nonce. Depois de validar a assinatura, Microsoft Entra ID valida a nonce assinada retornada. Depois de validar o nó, Microsoft Entra ID cria um PRT com chave de sessão criptografada para a chave de transporte do dispositivo e cria um TGT parcial de Microsoft Entra Kerberos e os retorna à Cloud AP. |
| D | O CLOUD AP recebe o PRT criptografado com chave de sessão. Usando a chave de transporte privado do dispositivo, o Cloud AP descriptografa a chave da sessão e protege a chave da sessão usando o TPM do dispositivo (se disponível). A CLOUD AP retorna uma resposta de autenticação bem-sucedida ao lsass. O Lsass armazena em cache o PRT e o TGT Parcial. |
| E | O provedor de suporte à segurança Kerberos, hospedado em lsass, usa metadados da chave Windows Hello para Empresas para obter uma dica do domínio do usuário. Usando a dica, o provedor usa o serviço DClocator para localizar um controlador de domínio. Depois de localizar um controlador de domínio ativo, o provedor Kerberos envia o TGT parcial que recebeu de Microsoft Entra ID para o controlador de domínio. O TGT parcial contém apenas o SID do usuário e é assinado por Microsoft Entra Kerberos. O controlador de domínio verifica se o TGT parcial é válido. Com êxito, o KDC retorna um TGT para o cliente. Kerberos retorna o TGT para lsass, onde é armazenado em cache e usado para solicitações de tíquetes de serviço subsequentes. O Lsass informa o Winlogon sobre a autenticação de sucesso. O Winlogon cria uma sessão de logon, carrega o perfil do usuário e inicia explorer.exe. |
Microsoft Entra autenticação de junção híbrida usando uma chave
| Fase | Descrição |
|---|---|
| A | A autenticação começa quando o usuário descarta a tela de bloqueio, que dispara o Winlogon para mostrar o provedor de credencial Windows Hello para Empresas. O usuário fornece seu gesto de Windows Hello (PIN ou biometria). O provedor de credencial empacota essas credenciais e as retorna ao Winlogon. Winlogon passa as credenciais coletadas para lsass. O Lsass passa as credenciais coletadas para o provedor de suporte de segurança Kerberos. O provedor Kerberos obtém dicas de domínio da estação de trabalho ingressada no domínio para localizar um controlador de domínio para o usuário. |
| B | O provedor Kerberos envia os dados de pré-autenticação assinados e a chave pública do usuário (na forma de um certificado autoassinado) para o serviço KDC (Key Distribution Center) em execução no controlador de domínio na forma de um KERB_AS_REQ. O controlador de domínio determina que o certificado é um certificado autoassinado. Ele recupera a chave pública do certificado incluído no KERB_AS_REQ e pesquisa a chave pública no Active Directory. Ele valida o UPN para solicitação de autenticação corresponde ao UPN registrado no Active Directory e valida os dados de pré-autenticação assinados usando a chave pública do Active Directory. Com êxito, o KDC retorna um TGT para o cliente com seu certificado em um KERB_AS_REP. |
| C | O provedor Kerberos garante que pode confiar na resposta do controlador de domínio. Primeiro, ele garante as cadeias de certificados KDC para um certificado raiz confiável pelo dispositivo. Em seguida, ele garante que o certificado esteja dentro de seu período de validade e que ele não tenha sido revogado. Em seguida, o provedor Kerberos verifica se o certificado tem a Autenticação KDC presente e que o nome alternativo do assunto listado no certificado do KDC corresponde ao nome de domínio ao qual o usuário está autenticando. |
| D | Depois de passar esse critério, Kerberos retorna o TGT para lsass, onde é armazenado em cache e usado para solicitações de tíquetes de serviço subsequentes. |
| E | O Lsass informa o Winlogon sobre a autenticação de sucesso. O Winlogon cria uma sessão de logon, carrega o perfil do usuário e inicia explorer.exe. |
| F | Enquanto o Windows carrega a área de trabalho do usuário, o lsass passa as credenciais coletadas para o provedor de suporte de segurança de Autenticação na Nuvem, conhecido como o provedor de AP de nuvem. O provedor de AP na nuvem solicita um nó de Microsoft Entra ID. Microsoft Entra ID retorna um nó. |
| G | O provedor de AP de nuvem assina o nó usando a chave privada do usuário e retorna a nonce assinada para o Microsoft Entra ID. Microsoft Entra ID valida a nonce assinada usando a chave pública registrada com segurança do usuário na assinatura de nonce. Depois de validar a assinatura, Microsoft Entra ID valida a nonce assinada retornada. Depois de validar o nó, Microsoft Entra ID cria um PRT com chave de sessão criptografada para a chave de transporte do dispositivo e retorna-a ao provedor de AP de nuvem. O provedor de AP de nuvem recebe o PRT criptografado com chave de sessão. Usando a chave de transporte privado do dispositivo, o provedor de CLOUD AP descriptografou a chave da sessão e protege a chave da sessão usando o TPM do dispositivo. O provedor de AP de nuvem retorna uma resposta de autenticação bem-sucedida ao lsass. O Lsass armazena em cache o PRT. |
Importante
No modelo de implantação acima, um usuário recém-provisionado não poderá entrar usando Windows Hello para Empresas até que (a) Microsoft Entra Connect sincronize com êxito a chave pública para o dispositivo Active Directory local e (b) tem linha de visão para o controlador de domínio pela primeira vez.
Microsoft Entra autenticação de junção híbrida usando um certificado
| Fase | Descrição |
|---|---|
| A | A autenticação começa quando o usuário descarta a tela de bloqueio, que dispara o Winlogon para mostrar o provedor de credencial Windows Hello para Empresas. O usuário fornece seu gesto de Windows Hello (PIN ou biometria). O provedor de credencial empacota essas credenciais e as retorna ao Winlogon. Winlogon passa as credenciais coletadas para lsass. O Lsass passa as credenciais coletadas para o provedor de suporte de segurança Kerberos. O provedor Kerberos obtém dicas de domínio da estação de trabalho ingressada no domínio para localizar um controlador de domínio para o usuário. |
| B | O provedor Kerberos envia os dados de pré-autenticação assinados e o certificado do usuário, que inclui a chave pública, para o serviço KDC (Key Distribution Center) em execução no controlador de domínio na forma de um KERB_AS_REQ. O controlador de domínio determina que o certificado não é certificado autoassinado. O controlador de domínio garante que as cadeias de certificados para o certificado raiz confiável, estejam dentro de seu período de validade, possam ser usadas para autenticação e não foram revogadas. Ele recupera a chave pública e o UPN do certificado incluído no KERB_AS_REQ e pesquisa o UPN no Active Directory. Ele valida os dados de pré-autenticação assinados usando a chave pública do certificado. Com êxito, o KDC retorna um TGT para o cliente com seu certificado em um KERB_AS_REP. |
| C | O provedor Kerberos garante que pode confiar na resposta do controlador de domínio. Primeiro, ele garante as cadeias de certificados KDC para um certificado raiz confiável pelo dispositivo. Em seguida, ele garante que o certificado esteja dentro de seu período de validade e que ele não tenha sido revogado. Em seguida, o provedor Kerberos verifica se o certificado tem a Autenticação KDC presente e que o nome alternativo do assunto listado no certificado do KDC corresponde ao nome de domínio ao qual o usuário está autenticando. |
| D | Depois de passar esse critério, Kerberos retorna o TGT para lsass, onde é armazenado em cache e usado para solicitações de tíquetes de serviço subsequentes. |
| E | O Lsass informa o Winlogon sobre a autenticação de sucesso. O Winlogon cria uma sessão de logon, carrega o perfil do usuário e inicia explorer.exe. |
| F | Enquanto o Windows carrega a área de trabalho do usuário, o lsass passa as credenciais coletadas para o provedor de suporte de segurança de Autenticação na Nuvem, conhecido como o provedor de AP de nuvem. O provedor de AP na nuvem solicita um nó de Microsoft Entra ID. Microsoft Entra ID retorna um nó. |
| G | O provedor de AP de nuvem assina o nó usando a chave privada do usuário e retorna a nonce assinada para o Microsoft Entra ID. Microsoft Entra ID valida a nonce assinada usando a chave pública registrada com segurança do usuário na assinatura de nonce. Depois de validar a assinatura, Microsoft Entra ID valida a nonce assinada retornada. Depois de validar o nó, Microsoft Entra ID cria um PRT com chave de sessão criptografada para a chave de transporte do dispositivo e retorna-a ao provedor de AP de nuvem. O provedor de AP de nuvem recebe o PRT criptografado com chave de sessão. Usando a chave de transporte privado do dispositivo, o provedor de CLOUD AP descriptografou a chave da sessão e protege a chave da sessão usando o TPM do dispositivo. O provedor de AP de nuvem retorna uma resposta de autenticação bem-sucedida ao lsass. O Lsass armazena em cache o PRT. |
Importante
No modelo de implantação acima, um usuário recém-provisionado não poderá entrar usando Windows Hello para Empresas a menos que o dispositivo tenha linha de visão para o controlador de domínio.