Windows Hello para Empresas provisionamento

Aplica-se a:

• Windows 10
• Windows 11

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 Azure Active Directory
• O tipo Windows Hello para Empresas implantação
• Se o ambiente for gerenciado ou federado

Lista de fluxos de provisionamento:

• Azure AD provisionamento ingressado em um ambiente gerenciado
• Azure AD provisionamento ingressado em um ambiente federado
• Provisionamento Azure AD ingressado em uma implantação de confiança na nuvem (versão prévia) em um ambiente gerenciado
• Provisionamento Azure AD ingressado em uma implantação de confiança de chave em um ambiente gerenciado
• Provisionamento Azure AD ingressado em uma implantação de confiança de certificado síncrona em um ambiente federado
• Provisionamento ingressado no domínio em uma implantação de confiança de chave local
• Provisionamento ingressado no domínio em uma implantação de confiança de certificado local

Observação

Os fluxos nesta seção não são exaustivos para todos os cenários possíveis. Por exemplo, a Confiança de Chave Federada também é uma configuração com suporte.

Azure AD provisionamento ingressado em um ambiente gerenciado

Imagem de tamanho completo

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 Dispositivos) do Azure. O aplicativo faz a solicitação usando o plug-in do Gerenciador de Contas da Web do Azure Active Directory. Os usuários devem fornecer dois fatores de autenticação. Nesta fase, o usuário já forneceu um fator de autenticação, normalmente nome de usuário e senha. O serviço de MFA do Azure fornece o segundo fator de autenticação. Se o usuário executou o Azure MFA nos últimos 10 minutos, como ao registrar o dispositivo da OOBE (experiência pronta para uso), ele não será solicitado a usar a MFA porque a MFA atual permanece válida. O Azure Active Directory valida a solicitação de token de acesso e a declaração de MFA associada a ela, cria um token de acesso ADRS e o retorna ao aplicativo.
B	Depois de receber um token de acesso ADRS, o aplicativo detecta se o dispositivo tem um sensor Windows Hello biométrico compatível. 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 padrão (e o gesto de fall-back quando usado com biometria). O usuário fornece e confirma seu PIN. Em seguida, o aplicativo solicita Windows Hello para Empresas par de chaves do pool de chaves de pré-geração, 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 para o ADRS para registro de chave de usuário. O DRS do Azure valida que a declaração de MFA permanece atual. Na validação bem-sucedida, o DRS do Azure localiza o objeto do usuário no Azure Active Directory, grava as informações de chave em um atributo de vários valores. As informações principais incluem uma referência ao dispositivo do qual ele foi criado. O Azure Active Directory retorna uma ID de chave para o aplicativo que sinaliza o fim do provisionamento de usuário e o aplicativo é encerrado.

Retornar para o início

Azure AD provisionamento ingressado em um ambiente federado

Imagem de tamanho completo

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 Dispositivos) do Azure. O aplicativo faz a solicitação usando o plug-in do Gerenciador de Contas da Web do Azure Active Directory. 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. Nesta fase, o usuário já forneceu um fator de autenticação, normalmente nome de usuário e senha. O serviço de MFA do Azure fornece o segundo fator de autenticação. Se o usuário executou o Azure MFA nos últimos 10 minutos, como ao registrar o dispositivo da OOBE (experiência pronta para uso), ele não será solicitado a usar a MFA porque a MFA atual permanece válida. O servidor STS local emite um token empresarial na MFA bem-sucedida. O aplicativo envia o token para o Azure Active Directory. O Azure Active Directory valida a solicitação de token de acesso e a declaração de MFA associada a ela, cria um token de acesso ADRS e o retorna ao aplicativo.
B	Depois de receber um token de acesso ADRS, o aplicativo detecta se o dispositivo tem um sensor Windows Hello biométrico compatível. 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 padrão (e o gesto de fall-back quando usado com biometria). O usuário fornece e confirma seu PIN. Em seguida, o aplicativo solicita Windows Hello para Empresas par de chaves do pool de chaves de pré-geração, 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 para o ADRS para registro de chave de usuário. O DRS do Azure valida se a declaração de MFA permanece atual. Na validação bem-sucedida, o DRS do Azure localiza o objeto do usuário no Azure Active Directory, grava as informações de chave em um atributo de vários valores. As informações principais incluem uma referência ao dispositivo do qual ele foi criado. O Azure Active Directory retorna a ID da chave para o aplicativo que sinaliza o fim do provisionamento de usuário e o aplicativo é encerrado.

Retornar para o início

Provisionamento Azure AD ingressado em uma implantação de confiança na nuvem (versão prévia) em um ambiente gerenciado

Imagem de tamanho completo

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 Dispositivos) do Azure. O aplicativo faz a solicitação usando o plug-in do Gerenciador de Contas da Web do Azure Active Directory. Os usuários devem fornecer dois fatores de autenticação. Nesta fase, o usuário já forneceu um fator de autenticação, normalmente nome de usuário e senha. O serviço de MFA do Azure fornece o segundo fator de autenticação. Se o usuário executou o Azure MFA nos últimos 10 minutos, como ao registrar o dispositivo da OOBE (experiência pronta para uso), ele não será solicitado a usar a MFA porque a MFA atual permanece válida. O Azure Active Directory valida a solicitação de token de acesso e a declaração de MFA associada a ela, cria um token de acesso ADRS e o retorna ao aplicativo.
B	Depois de receber um token de acesso ADRS, o aplicativo detecta se o dispositivo tem um sensor Windows Hello biométrico compatível. 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 padrão (e o gesto de fall-back quando usado com biometria). O usuário fornece e confirma seu PIN. Em seguida, o aplicativo solicita Windows Hello para Empresas par de chaves do pool de chaves de pré-geração, 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 para o ADRS para registro de chave de usuário. O DRS do Azure valida que a declaração de MFA permanece atual. Na validação bem-sucedida, o DRS do Azure localiza o objeto do usuário no Azure Active Directory, grava as informações de chave em um atributo de vários valores. As informações principais incluem uma referência ao dispositivo do qual ele foi criado. O Azure Active Directory retorna uma ID de chave para o aplicativo que sinaliza o fim do provisionamento de usuário e o aplicativo é encerrado.

Observação

Windows Hello para Empresas Cloud Trust não exige que as chaves dos usuários sejam sincronizadas do Azure AD para o AD. Os usuários podem se autenticar imediatamente no Azure Active Directory e no AD após o provisionamento de suas credenciais.

Retornar para o início

Provisionamento Azure AD ingressado em uma implantação de confiança de chave em um ambiente gerenciado

Imagem de tamanho completo

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 Dispositivos) do Azure. O aplicativo faz a solicitação usando o plug-in do Gerenciador de Contas da Web do Azure Active Directory. Os usuários devem fornecer dois fatores de autenticação. Nesta fase, o usuário já forneceu um fator de autenticação, normalmente nome de usuário e senha. O serviço de MFA do Azure fornece o segundo fator de autenticação. Se o usuário executou o Azure MFA nos últimos 10 minutos, como ao registrar o dispositivo da OOBE (experiência pronta para uso), ele não será solicitado a usar a MFA porque a MFA atual permanece válida. O Azure Active Directory valida a solicitação de token de acesso e a declaração de MFA associada a ela, cria um token de acesso ADRS e o retorna ao aplicativo.
B	Depois de receber um token de acesso ADRS, o aplicativo detecta se o dispositivo tem um sensor Windows Hello biométrico compatível. 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 padrão (e o gesto de fall-back quando usado com biometria). O usuário fornece e confirma seu PIN. Em seguida, o aplicativo solicita Windows Hello para Empresas par de chaves do pool de chaves de pré-geração, 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 para o ADRS para registro de chave de usuário. O DRS do Azure valida que a declaração de MFA permanece atual. Na validação bem-sucedida, o DRS do Azure localiza o objeto do usuário no Azure Active Directory, grava as informações de chave em um atributo de vários valores. As informações principais incluem uma referência ao dispositivo do qual ele foi criado. O Azure Active Directory retorna uma ID de chave para o aplicativo que sinaliza o fim do provisionamento de usuário e o aplicativo é encerrado.
D	Azure AD Connect solicita atualizações em seu próximo ciclo de sincronização. O Azure Active Directory envia a chave pública do usuário que foi registrada com segurança por meio do provisionamento. O Azure Active Directory Connect recebe a chave pública e a grava no atributo msDS-KeyCredentialLink do usuário no Active Directory.

Importante

O usuário recém-provisionado não poderá entrar usando o Windows Hello para Empresas até que o Azure AD Connect sincronize com êxito a chave pública com o Active Directory local.

Retornar para o início

Provisionamento Azure AD ingressado em uma implantação de confiança de certificado síncrona em um ambiente federado

Imagem de tamanho completo

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 Dispositivos) do Azure. O aplicativo faz a solicitação usando o plug-in do Gerenciador de Contas da Web do Azure Active Directory. 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. Nesta fase, o usuário já forneceu um fator de autenticação, normalmente nome de usuário e senha. O serviço MFA do Azure (ou um serviço de MFA de terceiros) fornece o segundo fator de autenticação. O servidor STS local emite um token empresarial na MFA bem-sucedida. O aplicativo envia o token para o Azure Active Directory. O Azure Active Directory valida a solicitação de token de acesso e a declaração de MFA associada a ela, cria um token de acesso ADRS e o retorna ao aplicativo.
B	Depois de receber um token de acesso ADRS, o aplicativo detecta se o dispositivo tem um sensor Windows Hello biométrico compatível. 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 padrão (e o gesto de fall-back quando usado com biometria). O usuário fornece e confirma seu PIN. Em seguida, o aplicativo solicita Windows Hello para Empresas par de chaves do pool de chaves de pré-geração, 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 para o ADRS para registro de chave de usuário. O DRS do Azure valida que a declaração de MFA permanece atual. Na validação bem-sucedida, o DRS do Azure localiza o objeto do usuário no Azure Active Directory, grava as informações de chave em um atributo de vários valores. As informações principais incluem uma referência ao dispositivo do qual ele foi criado. O Azure Active Directory retorna uma ID de chave e um recibo de chave para o aplicativo, que representa o final do registro de chave do usuário.
D	A parte de solicitação de certificado do provisionamento começa depois que o aplicativo recebe uma resposta bem-sucedida do registro de chave. O aplicativo cria uma solicitação de certificado PKCS nº 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 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 validará o recibo da chave para confirmar que 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 certificação de emissão da empresa. A autoridade de certificação valida que a solicitação de certificado foi 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 ao 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 do Azure AD Connect para sincronizar a chave pública do usuário para emitir o certificado de Windows Hello para Empresas autenticação. Os usuários podem entrar usando o certificado imediatamente após a conclusão do provisionamento. Azure AD Connect continua sincronizando a chave pública com o Active Directory, mas não é mostrado nesse fluxo.

Retornar para o início

Provisionamento ingressado no domínio em uma implantação de Confiança de Chave local

Imagem de tamanho completo

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 (Enterprise Device Registration Service). O aplicativo faz a solicitação usando o plug-in do Gerenciador de Contas da Web do Azure Active Directory. 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. Nesta fase, o usuário já forneceu um fator de autenticação, normalmente nome de usuário e senha. O servidor MFA do Azure (ou um serviço de MFA de terceiros) fornece o segundo fator de autenticação. O servidor STS local emite um token DRS corporativo na MFA bem-sucedida.
B	Depois de receber um token de acesso EDRS, o aplicativo detecta se o dispositivo tem um sensor Windows Hello biométrico compatível. 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 padrão (e o gesto de fall-back quando usado com biometria). O usuário fornece e confirma seu PIN. Em seguida, o aplicativo solicita Windows Hello para Empresas par de chaves do pool de chaves de pré-geração, 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 DRS enterprise para registro de chave de usuário. O DRS corporativo valida que a declaração de MFA permanece atual. Na validação bem-sucedida, o DRS Empresarial localiza o objeto do usuário no Active Directory, grava as informações de chave em um atributo de vários valores. As informações principais incluem uma referência ao dispositivo do qual ele foi criado. O DRS corporativo retorna uma ID de chave para o aplicativo, que representa o final do registro de chave do usuário.

Retornar para o início

Provisionamento ingressado no domínio em uma implantação de Confiança de Certificado local

Imagem de tamanho completo

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 (Enterprise Device Registration Service). O aplicativo faz a solicitação usando o plug-in do Gerenciador de Contas da Web do Azure Active Directory. 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. Nesta fase, o usuário já forneceu um fator de autenticação, normalmente nome de usuário e senha. O servidor MFA do Azure (ou um serviço de MFA de terceiros) fornece o segundo fator de autenticação. O servidor STS local emite um token DRS corporativo na MFA bem-sucedida.
B	Depois de receber um token de acesso EDRS, o aplicativo detecta se o dispositivo tem um sensor Windows Hello biométrico compatível. 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 padrão (e o gesto de fall-back quando usado com biometria). O usuário fornece e confirma seu PIN. Em seguida, o aplicativo solicita Windows Hello para Empresas par de chaves do pool de chaves de pré-geração, 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 DRS enterprise para registro de chave de usuário. O DRS corporativo valida que a declaração de MFA permanece atual. Na validação bem-sucedida, o DRS Empresarial localiza o objeto do usuário no Active Directory, grava as informações de chave em um atributo de vários valores. As informações principais incluem uma referência ao dispositivo do qual ele foi criado. O DRS corporativo retorna uma ID de chave para o aplicativo, que representa o final do registro de chave do usuário.
D	A parte de solicitação de certificado do provisionamento começa depois que o aplicativo recebe uma resposta bem-sucedida do registro de chave. O aplicativo cria uma solicitação de certificado PKCS nº 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 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 certificação de emissão da empresa. A autoridade de certificação valida que a solicitação de certificado foi 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 ao 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.

Retornar para o início