Como funciona o provisionamento do Windows Hello para Empresas
Windows Hello para Empresas provisionamento permite que um usuário registre uma credencial nova, forte e de dois fatores que ele pode usar para autenticação sem senha. A experiência de provisionamento varia de acordo com:
- Como o dispositivo é ingressado no Microsoft Entra ID
- O tipo de implantação Windows Hello para Empresas
- Se o ambiente for gerenciado ou federado
Observação
Os fluxos nesta seção não são exaustivos para todos os cenários possíveis. Por exemplo, o Federated Key Trust também é uma configuração com suporte.
Provisionamento para dispositivos ingressados Microsoft Entra com autenticação gerenciada
| Fase | Descrição |
|---|---|
| A | O aplicativo de provisionamento hospedado no CXH (Cloud Experience Host) inicia o provisionamento solicitando um token de acesso para o ADRS (Serviço de Registro de Dispositivo do Azure). O aplicativo faz a solicitação usando o plug-in Microsoft Entra Web Account Manager. Os usuários devem fornecer dois fatores de autenticação. Nessa fase, o usuário já forneceu um fator de autenticação, normalmente nome de usuário e senha. O serviço de autenticação multifator Microsoft Entra fornece o segundo fator de autenticação. Se o usuário tiver realizado Microsoft Entra autenticação multifator nos últimos 10 minutos, como ao registrar o dispositivo da OOBE (experiência fora de caixa), ele não será solicitado para MFA porque o MFA atual permanece válido. Microsoft Entra ID valida a solicitação de token de acesso e a declaração MFA associada a ela, cria um token de acesso do ADRS e o retorna ao aplicativo. |
| B | Depois de receber um token de acesso do ADRS, o aplicativo detecta se o dispositivo tem um sensor compatível com biometria Windows Hello. Se o aplicativo detectar um sensor biométrico, ele dará ao usuário a opção de registrar a biometria. Depois de concluir ou ignorar o registro biométrico, o aplicativo exige que o usuário crie um PIN e o gesto padrão (e fall-back quando usado com biometria). O usuário fornece e confirma seu PIN. Em seguida, o aplicativo solicita um par de chaves Windows Hello para Empresas do pool de pré-regeneração de chave, que inclui dados de atestado. Essa é a chave de usuário (ukpub/ukpriv). |
| C | O aplicativo envia o token ADRS, ukpub, dados de atestado e informações do dispositivo ao ADRS para registro de chave de usuário. O DRS do Azure valida que a declaração MFA permanece atual. Em validação bem-sucedida, o DRS do Azure localiza o objeto do usuário em Microsoft Entra ID, grava as informações de chave em um atributo de vários valores. As principais informações incluem uma referência ao dispositivo do qual ele foi criado. Microsoft Entra ID retorna uma ID de chave para o aplicativo, que sinaliza o fim do provisionamento do usuário e as saídas do aplicativo. |
Provisionamento para dispositivos ingressados Microsoft Entra com autenticação federada
| Fase | Descrição |
|---|---|
| A | O aplicativo de provisionamento hospedado no CXH (Cloud Experience Host) inicia o provisionamento solicitando um token de acesso para o ADRS (Serviço de Registro de Dispositivo do Azure). O aplicativo faz a solicitação usando o plug-in Microsoft Entra Web Account Manager. Em um ambiente federado, o plug-in envia a solicitação de token para o STS local, como Serviços de Federação do Active Directory (AD FS). O STS local autentica o usuário e determina se o usuário deve executar outro fator de autenticação. Os usuários devem fornecer dois fatores de autenticação. Nessa fase, o usuário já forneceu um fator de autenticação, normalmente nome de usuário e senha. O serviço de autenticação multifator Microsoft Entra fornece o segundo fator de autenticação. Se o usuário tiver realizado Microsoft Entra autenticação multifator nos últimos 10 minutos, como ao registrar o dispositivo da OOBE (experiência fora de caixa), ele não será solicitado para MFA porque o MFA atual permanece válido. O servidor STS local emite um token corporativo no MFA bem-sucedido. O aplicativo envia o token para Microsoft Entra ID. Microsoft Entra ID valida a solicitação de token de acesso e a declaração MFA associada a ela, cria um token de acesso do ADRS e o retorna ao aplicativo. |
| B | Depois de receber um token de acesso do ADRS, o aplicativo detecta se o dispositivo tem um sensor compatível com biometria Windows Hello. Se o aplicativo detectar um sensor biométrico, ele dará ao usuário a opção de registrar a biometria. Depois de concluir ou ignorar o registro biométrico, o aplicativo exige que o usuário crie um PIN e o gesto padrão (e fall-back quando usado com biometria). O usuário fornece e confirma seu PIN. Em seguida, o aplicativo solicita um par de chaves Windows Hello para Empresas do pool de pré-regeneração de chave, que inclui dados de atestado. Essa é a chave de usuário (ukpub/ukpriv). |
| C | O aplicativo envia o token ADRS, ukpub, dados de atestado e informações do dispositivo ao ADRS para registro de chave de usuário. O DRS do Azure valida a declaração de MFA permanece atual. Em validação bem-sucedida, o DRS do Azure localiza o objeto do usuário em Microsoft Entra ID, grava as informações de chave em um atributo de vários valores. As principais informações incluem uma referência ao dispositivo do qual ele foi criado. Microsoft Entra ID retorna a ID da chave para o aplicativo, o que sinaliza o fim do provisionamento do usuário e as saídas do aplicativo. |
Provisionamento em um modelo de implantação de confiança kerberos de nuvem com autenticação gerenciada
| Fase | Descrição |
|---|---|
| A | O aplicativo de provisionamento hospedado no CXH (Cloud Experience Host) inicia o provisionamento solicitando um token de acesso para o ADRS (Serviço de Registro de Dispositivo do Azure). O aplicativo faz a solicitação usando o plug-in Microsoft Entra Web Account Manager. Os usuários devem fornecer dois fatores de autenticação. Nessa fase, o usuário já forneceu um fator de autenticação, normalmente nome de usuário e senha. O serviço de autenticação multifator Microsoft Entra fornece o segundo fator de autenticação. Se o usuário tiver realizado Microsoft Entra autenticação multifator nos últimos 10 minutos, como ao registrar o dispositivo da OOBE (experiência fora de caixa), ele não será solicitado para MFA porque o MFA atual permanece válido. Microsoft Entra ID valida a solicitação de token de acesso e a declaração MFA associada a ela, cria um token de acesso do ADRS e o retorna ao aplicativo. |
| B | Depois de receber um token de acesso do ADRS, o aplicativo detecta se o dispositivo tem um sensor compatível com biometria Windows Hello. Se o aplicativo detectar um sensor biométrico, ele dará ao usuário a opção de registrar a biometria. Depois de concluir ou ignorar o registro biométrico, o aplicativo exige que o usuário crie um PIN e o gesto padrão (e fall-back quando usado com biometria). O usuário fornece e confirma seu PIN. Em seguida, o aplicativo solicita um par de chaves Windows Hello para Empresas do pool de pré-regeneração de chave, que inclui dados de atestado. Essa é a chave de usuário (ukpub/ukpriv). |
| C | O aplicativo envia o token ADRS, ukpub, dados de atestado e informações do dispositivo ao ADRS para registro de chave de usuário. O DRS do Azure valida que a declaração MFA permanece atual. Em validação bem-sucedida, o DRS do Azure localiza o objeto do usuário em Microsoft Entra ID, grava as informações de chave em um atributo de vários valores. As principais informações incluem uma referência ao dispositivo do qual ele foi criado. Microsoft Entra ID retorna uma ID de chave para o aplicativo, que sinaliza o fim do provisionamento do usuário e as saídas do aplicativo. |
Observação
Windows Hello para Empresas confiança kerberos na nuvem não exige que as chaves dos usuários sejam sincronizadas de Microsoft Entra ID para o Active Directory. Os usuários podem autenticar-se imediatamente no Microsoft Entra ID e no AD depois de provisionar sua credencial.
Provisionamento em um modelo de implantação de confiança de chave híbrida com autenticação gerenciada
| Fase | Descrição |
|---|---|
| A | O aplicativo de provisionamento hospedado no CXH (Cloud Experience Host) inicia o provisionamento solicitando um token de acesso para o ADRS (Serviço de Registro de Dispositivo do Azure). O aplicativo faz a solicitação usando o plug-in Microsoft Entra Web Account Manager. Os usuários devem fornecer dois fatores de autenticação. Nessa fase, o usuário já forneceu um fator de autenticação, normalmente nome de usuário e senha. O serviço de autenticação multifator Microsoft Entra fornece o segundo fator de autenticação. Se o usuário tiver realizado Microsoft Entra autenticação multifator nos últimos 10 minutos, como ao registrar o dispositivo da OOBE (experiência fora de caixa), ele não será solicitado para MFA porque o MFA atual permanece válido. Microsoft Entra ID valida a solicitação de token de acesso e a declaração MFA associada a ela, cria um token de acesso do ADRS e o retorna ao aplicativo. |
| B | Depois de receber um token de acesso do ADRS, o aplicativo detecta se o dispositivo tem um sensor compatível com biometria Windows Hello. Se o aplicativo detectar um sensor biométrico, ele dará ao usuário a opção de registrar a biometria. Depois de concluir ou ignorar o registro biométrico, o aplicativo exige que o usuário crie um PIN e o gesto padrão (e fall-back quando usado com biometria). O usuário fornece e confirma seu PIN. Em seguida, o aplicativo solicita um par de chaves Windows Hello para Empresas do pool de pré-regeneração de chave, que inclui dados de atestado. Essa é a chave de usuário (ukpub/ukpriv). |
| C | O aplicativo envia o token ADRS, ukpub, dados de atestado e informações do dispositivo ao ADRS para registro de chave de usuário. O DRS do Azure valida que a declaração MFA permanece atual. Em validação bem-sucedida, o DRS do Azure localiza o objeto do usuário em Microsoft Entra ID, grava as informações de chave em um atributo de vários valores. As principais informações incluem uma referência ao dispositivo do qual ele foi criado. Microsoft Entra ID retorna uma ID de chave para o aplicativo, que sinaliza o fim do provisionamento do usuário e as saídas do aplicativo. |
| D | Microsoft Entra Connect solicita atualizações em seu próximo ciclo de sincronização. Microsoft Entra ID envia a chave pública do usuário que foi registrada com segurança por meio do provisionamento. Microsoft Entra Connect recebe a chave pública e grava-a no atributo do msDS-KeyCredentialLink usuário no Active Directory. |
Importante
O usuário recém-provisionado não poderá entrar usando Windows Hello para Empresas até que Microsoft Entra Connect sincronize com êxito a chave pública para o Active Directory local.
Provisionamento em um modelo de implantação de confiança de certificado híbrido com autenticação federada
| Fase | Descrição |
|---|---|
| A | O aplicativo de provisionamento hospedado no CXH (Cloud Experience Host) inicia o provisionamento solicitando um token de acesso para o ADRS (Serviço de Registro de Dispositivo do Azure). O aplicativo faz a solicitação usando o plug-in Microsoft Entra Web Account Manager. Em um ambiente federado, o plug-in envia a solicitação de token para o STS local, como Serviços de Federação do Active Directory (AD FS). O STS local autentica o usuário e determina se o usuário deve executar outro fator de autenticação. Os usuários devem fornecer dois fatores de autenticação. Nessa fase, o usuário já forneceu um fator de autenticação, normalmente nome de usuário e senha. O Microsoft Entra serviço de autenticação multifator (ou um serviço não Microsoft MFA) fornece o segundo fator de autenticação. O servidor STS local emite um token corporativo no MFA bem-sucedido. O aplicativo envia o token para Microsoft Entra ID. Microsoft Entra ID valida a solicitação de token de acesso e a declaração MFA associada a ela, cria um token de acesso do ADRS e o retorna ao aplicativo. |
| B | Depois de receber um token de acesso do ADRS, o aplicativo detecta se o dispositivo tem um sensor compatível com biometria Windows Hello. Se o aplicativo detectar um sensor biométrico, ele dará ao usuário a opção de registrar a biometria. Depois de concluir ou ignorar o registro biométrico, o aplicativo exige que o usuário crie um PIN e o gesto padrão (e fall-back quando usado com biometria). O usuário fornece e confirma seu PIN. Em seguida, o aplicativo solicita um par de chaves Windows Hello para Empresas do pool de pré-regeneração de chave, que inclui dados de atestado. Essa é a chave de usuário (ukpub/ukpriv). |
| C | O aplicativo envia o token ADRS, ukpub, dados de atestado e informações do dispositivo ao ADRS para registro de chave de usuário. O DRS do Azure valida que a declaração MFA permanece atual. Em validação bem-sucedida, o DRS do Azure localiza o objeto do usuário em Microsoft Entra ID, grava as informações de chave em um atributo de vários valores. As principais informações incluem uma referência ao dispositivo do qual ele foi criado. Microsoft Entra ID retorna uma ID de chave e um recibo de chave para o aplicativo, que representa o fim do registro da chave de usuário. |
| D | A parte da solicitação de certificado do provisionamento começa após o aplicativo receber uma resposta bem-sucedida do registro de chave. O aplicativo cria uma solicitação de certificado PKCS#10. A chave usada na solicitação de certificado é a mesma chave que foi provisionada com segurança. O aplicativo envia o recibo de chave e a solicitação de certificado, que inclui a chave pública, para a autoridade de registro de certificado hospedada no farm do Serviços de Federação do Active Directory (AD FS) (AD FS). Depois de receber a solicitação de certificado, a autoridade de registro de certificado consulta o Active Directory para o msDS-KeyCredentialsLink para obter uma lista de chaves públicas registradas. |
| E | A autoridade de registro valida a chave pública na solicitação de certificado que corresponde a uma chave registrada para o usuário. Se a chave pública no certificado não for encontrada na lista de chaves públicas registradas, ela valida o recibo de chave para confirmar se a chave foi registrada com segurança no Azure. Depois de validar o recibo de chave ou a chave pública, a autoridade de registro assina a solicitação de certificado usando seu certificado de agente de registro. |
| F | A autoridade de registro envia a solicitação de certificado para a autoridade de certificado de emissão da empresa. A autoridade de certificado valida que a solicitação de certificado é assinada por um agente de registro válido e, com êxito, emite um certificado e o retorna à autoridade de registro que, em seguida, retorna o certificado para o aplicativo. |
| G | O aplicativo recebe o certificado recém-emitido e o instala no repositório pessoal do usuário. Isso sinaliza o fim do provisionamento. |
Importante
O registro de certificado síncrono não depende de Microsoft Entra Conectar para sincronizar a chave pública do usuário para emitir o certificado de autenticação Windows Hello para Empresas. Os usuários podem entrar usando o certificado imediatamente após a conclusão do provisionamento. Microsoft Entra Connect continua a sincronizar a chave pública com o Active Directory, mas não é mostrado nesse fluxo.
Provisionamento em um modelo de implantação de confiança de chave local
| Fase | Descrição |
|---|---|
| A | O aplicativo de provisionamento hospedado no CXH (Cloud Experience Host) inicia o provisionamento solicitando um token de acesso para o EDRS (Serviço de Registro de Dispositivo Empresarial). O aplicativo faz a solicitação usando o plug-in Microsoft Entra Web Account Manager. Em uma implantação local, o plug-in envia a solicitação de token para o STS local, como Serviços de Federação do Active Directory (AD FS). O STS local autentica o usuário e determina se o usuário deve executar outro fator de autenticação. Os usuários devem fornecer dois fatores de autenticação. Nessa fase, o usuário já forneceu um fator de autenticação, normalmente nome de usuário e senha. Microsoft Entra servidor de autenticação multifator (ou um serviço não Microsoft MFA) fornece o segundo fator de autenticação. O servidor STS local emite um token DRS corporativo no MFA bem-sucedido. |
| B | Depois de receber um token de acesso EDRS, o aplicativo detecta se o dispositivo tem um sensor compatível com biometria Windows Hello. Se o aplicativo detectar um sensor biométrico, ele dará ao usuário a opção de registrar a biometria. Depois de concluir ou ignorar o registro biométrico, o aplicativo exige que o usuário crie um PIN e o gesto padrão (e fall-back quando usado com biometria). O usuário fornece e confirma seu PIN. Em seguida, o aplicativo solicita um par de chaves Windows Hello para Empresas do pool de pré-regeneração de chave, que inclui dados de atestado. Essa é a chave de usuário (ukpub/ukpriv). |
| C | O aplicativo envia o token EDRS, ukpub, dados de atestado e informações do dispositivo para o ENTERPRISE DRS para registro de chave de usuário. O DRS da empresa valida que a declaração MFA permanece atual. Em validação bem-sucedida, o ENTERPRISE DRS localiza o objeto do usuário no Active Directory, grava as informações-chave em um atributo de vários valores. As principais informações incluem uma referência ao dispositivo do qual ele foi criado. O DRS da Empresa retorna uma ID de chave para o aplicativo, que representa o fim do registro da chave de usuário. |
Provisionamento em um modelo de implantação de confiança de certificado local
| Fase | Descrição |
|---|---|
| A | O aplicativo de provisionamento hospedado no CXH (Cloud Experience Host) inicia o provisionamento solicitando um token de acesso para o EDRS (Serviço de Registro de Dispositivo Empresarial). O aplicativo faz a solicitação usando o plug-in Microsoft Entra Web Account Manager. Em uma implantação local, o plug-in envia a solicitação de token para o STS local, como Serviços de Federação do Active Directory (AD FS). O STS local autentica o usuário e determina se o usuário deve executar outro fator de autenticação. Os usuários devem fornecer dois fatores de autenticação. Nessa fase, o usuário já forneceu um fator de autenticação, normalmente nome de usuário e senha. Microsoft Entra servidor de autenticação multifator (ou um serviço não Microsoft MFA) fornece o segundo fator de autenticação. O servidor STS local emite um token DRS corporativo no MFA bem-sucedido. |
| B | Depois de receber um token de acesso EDRS, o aplicativo detecta se o dispositivo tem um sensor compatível com biometria Windows Hello. Se o aplicativo detectar um sensor biométrico, ele dará ao usuário a opção de registrar a biometria. Depois de concluir ou ignorar o registro biométrico, o aplicativo exige que o usuário crie um PIN e o gesto padrão (e fall-back quando usado com biometria). O usuário fornece e confirma seu PIN. Em seguida, o aplicativo solicita um par de chaves Windows Hello para Empresas do pool de pré-regeneração de chave, que inclui dados de atestado. Essa é a chave de usuário (ukpub/ukpriv). |
| C | O aplicativo envia o token EDRS, ukpub, dados de atestado e informações do dispositivo para o ENTERPRISE DRS para registro de chave de usuário. O DRS da empresa valida que a declaração MFA permanece atual. Em validação bem-sucedida, o ENTERPRISE DRS localiza o objeto do usuário no Active Directory, grava as informações-chave em um atributo de vários valores. As principais informações incluem uma referência ao dispositivo do qual ele foi criado. O DRS da Empresa retorna uma ID de chave para o aplicativo, que representa o fim do registro da chave de usuário. |
| D | A parte da solicitação de certificado do provisionamento começa após o aplicativo receber uma resposta bem-sucedida do registro de chave. O aplicativo cria uma solicitação de certificado PKCS#10. A chave usada na solicitação de certificado é a mesma chave que foi provisionada com segurança. O aplicativo envia a solicitação de certificado, que inclui a chave pública, para a autoridade de registro de certificado hospedada no farm do Serviços de Federação do Active Directory (AD FS) (AD FS). Depois de receber a solicitação de certificado, a autoridade de registro de certificado consulta o Active Directory para o msDS-KeyCredentialsLink para obter uma lista de chaves públicas registradas. |
| E | A autoridade de registro valida a chave pública na solicitação de certificado que corresponde a uma chave registrada para o usuário. Depois de validar a chave pública, a autoridade de registro assina a solicitação de certificado usando seu certificado de agente de registro. |
| F | A autoridade de registro envia a solicitação de certificado para a autoridade de certificado de emissão da empresa. A autoridade de certificado valida que a solicitação de certificado é assinada por um agente de registro válido e, com êxito, emite um certificado e o retorna à autoridade de registro que, em seguida, retorna o certificado para o aplicativo. |
| G | O aplicativo recebe o certificado recém-emitido e o instala no repositório pessoal do usuário. Isso sinaliza o fim do provisionamento. |