Fonctionnement de l’approvisionnement de Windows Hello Entreprise

  • Article

Windows Hello Entreprise’approvisionnement permet à un utilisateur d’inscrire de nouvelles informations d’identification fortes et à deux facteurs qu’il peut utiliser pour l’authentification sans mot de passe. L’expérience d’approvisionnement varie en fonction des points suivants :

  • Comment l’appareil est joint à Microsoft Entra ID
  • Type de déploiement Windows Hello Entreprise
  • Si l’environnement est géré ou fédéré

Remarque

Les flux de cette section ne sont pas exhaustifs pour tous les scénarios possibles. Par exemple, l’approbation de clé fédérée est également une configuration prise en charge.

Provisionnement pour les appareils joints Microsoft Entra avec l’authentification managée

Diagramme de séquence du flux d’approvisionnement Windows Hello pour les appareils Microsoft Entra joints avec l’authentification managée.

Phase Description
A L’application d’approvisionnement hébergée dans l’hôte d’expérience cloud (CXH) commence l’approvisionnement en demandant un jeton d’accès pour azure Device Registration Service (ADRS). L’application effectue la demande à l’aide du plug-in gestionnaire de compte web Microsoft Entra.
Les utilisateurs doivent fournir deux facteurs d’authentification. Dans cette phase, l’utilisateur a déjà fourni un facteur d’authentification, généralement le nom d’utilisateur et le mot de passe. Le service d’authentification multifacteur Microsoft Entra fournit le deuxième facteur d’authentification. Si l’utilisateur a effectué Microsoft Entra authentification multifacteur au cours des 10 dernières minutes, par exemple lors de l’inscription de l’appareil à partir de l’OOBE (out-of-box-experience), il n’est pas invité à entrer l’authentification multifacteur, car l’authentification multifacteur actuelle reste valide.
Microsoft Entra ID valide la demande de jeton d’accès et la revendication MFA associée, crée un jeton d’accès ADRS et le retourne à l’application.
B Après avoir reçu un jeton d’accès ADRS, l’application détecte si l’appareil dispose d’un capteur compatible Windows Hello biométrie. Si l’application détecte un capteur biométrique, elle donne à l’utilisateur le choix d’inscrire la biométrie. Une fois l’inscription biométrique terminée ou ignorée, l’application exige que l’utilisateur crée un code confidentiel et le mouvement par défaut (et un mouvement de secours lorsqu’il est utilisé avec la biométrie). L’utilisateur fournit et confirme son code confidentiel. Ensuite, l’application demande une paire de clés Windows Hello Entreprise à partir du pool de clés de prégénération, qui inclut des données d’attestation. Il s’agit de la clé utilisateur (ukpub/ukpriv).
C L’application envoie le jeton ADRS, ukpub, les données d’attestation et les informations d’appareil à ADRS pour l’inscription de clé utilisateur. Azure DRS vérifie que la revendication MFA reste à jour. Une fois la validation réussie, Azure DRS localise l’objet de l’utilisateur dans Microsoft Entra ID, écrit les informations clés dans un attribut à valeurs multiples. Les informations clés incluent une référence à l’appareil à partir duquel elles ont été créées. Microsoft Entra ID retourne un ID de clé à l’application, qui signale la fin de l’approvisionnement des utilisateurs et la fermeture de l’application.

Approvisionnement d’appareils joints Microsoft Entra avec authentification fédérée

Diagramme séquentiel du flux d’approvisionnement Windows Hello pour Microsoft Entra appareils joints avec authentification fédérée.

Phase Description
A L’application d’approvisionnement hébergée dans l’hôte d’expérience cloud (CXH) commence l’approvisionnement en demandant un jeton d’accès pour azure Device Registration Service (ADRS). L’application effectue la demande à l’aide du plug-in gestionnaire de compte web Microsoft Entra.
Dans un environnement fédéré, le plug-in envoie la demande de jeton au service STS local, par exemple Services ADFS. Le service STS local authentifie l’utilisateur et détermine si l’utilisateur doit effectuer un autre facteur d’authentification.
Les utilisateurs doivent fournir deux facteurs d’authentification. Dans cette phase, l’utilisateur a déjà fourni un facteur d’authentification, généralement le nom d’utilisateur et le mot de passe. Le service d’authentification multifacteur Microsoft Entra fournit le deuxième facteur d’authentification. Si l’utilisateur a effectué Microsoft Entra authentification multifacteur au cours des 10 dernières minutes, par exemple lors de l’inscription de l’appareil à partir de l’OOBE (out-of-box-experience), il n’est pas invité à entrer l’authentification multifacteur, car l’authentification multifacteur actuelle reste valide.
Le serveur STS local émet un jeton d’entreprise en cas d’authentification multifacteur réussie. L’application envoie le jeton à Microsoft Entra ID.
Microsoft Entra ID valide la demande de jeton d’accès et la revendication MFA associée, crée un jeton d’accès ADRS et le retourne à l’application.
B Après avoir reçu un jeton d’accès ADRS, l’application détecte si l’appareil dispose d’un capteur compatible Windows Hello biométrie. Si l’application détecte un capteur biométrique, elle donne à l’utilisateur le choix d’inscrire la biométrie. Une fois l’inscription biométrique terminée ou ignorée, l’application exige que l’utilisateur crée un code confidentiel et le mouvement par défaut (et un mouvement de secours lorsqu’il est utilisé avec la biométrie). L’utilisateur fournit et confirme son code confidentiel. Ensuite, l’application demande une paire de clés Windows Hello Entreprise à partir du pool de clés de prégénération, qui inclut des données d’attestation. Il s’agit de la clé utilisateur (ukpub/ukpriv).
C L’application envoie le jeton ADRS, ukpub, les données d’attestation et les informations d’appareil à ADRS pour l’inscription de clé utilisateur. Azure DRS vérifie que la revendication MFA reste à jour. Une fois la validation réussie, Azure DRS localise l’objet de l’utilisateur dans Microsoft Entra ID, écrit les informations clés dans un attribut à valeurs multiples. Les informations clés incluent une référence à l’appareil à partir duquel elles ont été créées. Microsoft Entra ID retourne l’ID de clé à l’application, ce qui signale la fin de l’approvisionnement de l’utilisateur et la fermeture de l’application.

Provisionnement dans un modèle de déploiement d’approbation Kerberos cloud avec authentification managée

Diagramme de séquence du flux d’approvisionnement Windows Hello dans un modèle de déploiement d’approbation Kerberos cloud hybride avec authentification managée.

Phase Description
A L’application d’approvisionnement hébergée dans l’hôte d’expérience cloud (CXH) commence l’approvisionnement en demandant un jeton d’accès pour azure Device Registration Service (ADRS). L’application effectue la demande à l’aide du plug-in gestionnaire de compte web Microsoft Entra.
Les utilisateurs doivent fournir deux facteurs d’authentification. Dans cette phase, l’utilisateur a déjà fourni un facteur d’authentification, généralement le nom d’utilisateur et le mot de passe. Le service d’authentification multifacteur Microsoft Entra fournit le deuxième facteur d’authentification. Si l’utilisateur a effectué Microsoft Entra authentification multifacteur au cours des 10 dernières minutes, par exemple lors de l’inscription de l’appareil à partir de l’OOBE (out-of-box-experience), il n’est pas invité à entrer l’authentification multifacteur, car l’authentification multifacteur actuelle reste valide.
Microsoft Entra ID valide la demande de jeton d’accès et la revendication MFA associée, crée un jeton d’accès ADRS et le retourne à l’application.
B Après avoir reçu un jeton d’accès ADRS, l’application détecte si l’appareil dispose d’un capteur compatible Windows Hello biométrie. Si l’application détecte un capteur biométrique, elle donne à l’utilisateur le choix d’inscrire la biométrie. Une fois l’inscription biométrique terminée ou ignorée, l’application exige que l’utilisateur crée un code confidentiel et le mouvement par défaut (et un mouvement de secours lorsqu’il est utilisé avec la biométrie). L’utilisateur fournit et confirme son code confidentiel. Ensuite, l’application demande une paire de clés Windows Hello Entreprise à partir du pool de clés de prégénération, qui inclut des données d’attestation. Il s’agit de la clé utilisateur (ukpub/ukpriv).
C L’application envoie le jeton ADRS, ukpub, les données d’attestation et les informations d’appareil à ADRS pour l’inscription de clé utilisateur. Azure DRS vérifie que la revendication MFA reste à jour. Une fois la validation réussie, Azure DRS localise l’objet de l’utilisateur dans Microsoft Entra ID, écrit les informations clés dans un attribut à valeurs multiples. Les informations clés incluent une référence à l’appareil à partir duquel elles ont été créées. Microsoft Entra ID retourne un ID de clé à l’application, qui signale la fin de l’approvisionnement des utilisateurs et la fermeture de l’application.

Remarque

Windows Hello Entreprise’approbation Kerberos cloud ne nécessite pas que les clés des utilisateurs soient synchronisées entre Microsoft Entra ID et Active Directory. Les utilisateurs peuvent s’authentifier immédiatement auprès de Microsoft Entra ID et AD après avoir approvisionné leurs informations d’identification.

Provisionnement dans un modèle de déploiement d’approbation de clé hybride avec authentification managée

Diagramme de séquence du flux d’approvisionnement Windows Hello dans un modèle de déploiement d’approbation de clé hybride avec authentification managée.

Phase Description
A L’application d’approvisionnement hébergée dans l’hôte d’expérience cloud (CXH) commence l’approvisionnement en demandant un jeton d’accès pour azure Device Registration Service (ADRS). L’application effectue la demande à l’aide du plug-in gestionnaire de compte web Microsoft Entra.
Les utilisateurs doivent fournir deux facteurs d’authentification. Dans cette phase, l’utilisateur a déjà fourni un facteur d’authentification, généralement le nom d’utilisateur et le mot de passe. Le service d’authentification multifacteur Microsoft Entra fournit le deuxième facteur d’authentification. Si l’utilisateur a effectué Microsoft Entra authentification multifacteur au cours des 10 dernières minutes, par exemple lors de l’inscription de l’appareil à partir de l’OOBE (out-of-box-experience), il n’est pas invité à entrer l’authentification multifacteur, car l’authentification multifacteur actuelle reste valide.
Microsoft Entra ID valide la demande de jeton d’accès et la revendication MFA associée, crée un jeton d’accès ADRS et le retourne à l’application.
B Après avoir reçu un jeton d’accès ADRS, l’application détecte si l’appareil dispose d’un capteur compatible Windows Hello biométrie. Si l’application détecte un capteur biométrique, elle donne à l’utilisateur le choix d’inscrire la biométrie. Une fois l’inscription biométrique terminée ou ignorée, l’application exige que l’utilisateur crée un code confidentiel et le mouvement par défaut (et un mouvement de secours lorsqu’il est utilisé avec la biométrie). L’utilisateur fournit et confirme son code confidentiel. Ensuite, l’application demande une paire de clés Windows Hello Entreprise à partir du pool de clés de prégénération, qui inclut des données d’attestation. Il s’agit de la clé utilisateur (ukpub/ukpriv).
C L’application envoie le jeton ADRS, ukpub, les données d’attestation et les informations d’appareil à ADRS pour l’inscription de clé utilisateur. Azure DRS vérifie que la revendication MFA reste à jour. Une fois la validation réussie, Azure DRS localise l’objet de l’utilisateur dans Microsoft Entra ID, écrit les informations clés dans un attribut à valeurs multiples. Les informations clés incluent une référence à l’appareil à partir duquel elles ont été créées. Microsoft Entra ID retourne un ID de clé à l’application, qui signale la fin de l’approvisionnement des utilisateurs et la fermeture de l’application.
D Microsoft Entra Connect demande des mises à jour à son prochain cycle de synchronisation. Microsoft Entra ID envoie la clé publique de l’utilisateur qui a été inscrite en toute sécurité par le biais de l’approvisionnement. Microsoft Entra Connect reçoit la clé publique et l’écrit dans l’attribut de msDS-KeyCredentialLink l’utilisateur dans Active Directory.

Important

L’utilisateur nouvellement approvisionné ne pourra pas se connecter à l’aide de Windows Hello Entreprise tant que Microsoft Entra Connect n’aura pas correctement synchronisé la clé publique avec le Active Directory local.

Provisionnement dans un modèle de déploiement d’approbation de certificat hybride avec authentification fédérée

Diagramme séquentiel du flux d’approvisionnement Windows Hello dans un modèle de déploiement d’approbation de certificat hybride avec authentification fédérée.

Phase Description
A L’application d’approvisionnement hébergée dans l’hôte d’expérience cloud (CXH) commence l’approvisionnement en demandant un jeton d’accès pour azure Device Registration Service (ADRS). L’application effectue la demande à l’aide du plug-in gestionnaire de compte web Microsoft Entra.
Dans un environnement fédéré, le plug-in envoie la demande de jeton au service STS local, par exemple Services ADFS. Le service STS local authentifie l’utilisateur et détermine si l’utilisateur doit effectuer un autre facteur d’authentification.
Les utilisateurs doivent fournir deux facteurs d’authentification. Dans cette phase, l’utilisateur a déjà fourni un facteur d’authentification, généralement le nom d’utilisateur et le mot de passe. Le Microsoft Entra service d’authentification multifacteur (ou un service non Microsoft MFA) fournit le deuxième facteur d’authentification.
Le serveur STS local émet un jeton d’entreprise en cas d’authentification multifacteur réussie. L’application envoie le jeton à Microsoft Entra ID.
Microsoft Entra ID valide la demande de jeton d’accès et la revendication MFA associée, crée un jeton d’accès ADRS et le retourne à l’application.
B Après avoir reçu un jeton d’accès ADRS, l’application détecte si l’appareil dispose d’un capteur compatible Windows Hello biométrie. Si l’application détecte un capteur biométrique, elle donne à l’utilisateur le choix d’inscrire la biométrie. Une fois l’inscription biométrique terminée ou ignorée, l’application exige que l’utilisateur crée un code confidentiel et le mouvement par défaut (et un mouvement de secours lorsqu’il est utilisé avec la biométrie). L’utilisateur fournit et confirme son code confidentiel. Ensuite, l’application demande une paire de clés Windows Hello Entreprise à partir du pool de clés de prégénération, qui inclut des données d’attestation. Il s’agit de la clé utilisateur (ukpub/ukpriv).
C L’application envoie le jeton ADRS, ukpub, les données d’attestation et les informations d’appareil à ADRS pour l’inscription de clé utilisateur. Azure DRS vérifie que la revendication MFA reste à jour. Une fois la validation réussie, Azure DRS localise l’objet de l’utilisateur dans Microsoft Entra ID, écrit les informations clés dans un attribut à valeurs multiples. Les informations clés incluent une référence à l’appareil à partir duquel elles ont été créées. Microsoft Entra ID retourne un ID de clé et un reçu de clé à l’application, qui représente la fin de l’inscription de la clé utilisateur.
D La partie demande de certificat de l’approvisionnement commence une fois que l’application a reçu une réponse réussie de l’inscription de clé. L’application crée une demande de certificat PKCS#10. La clé utilisée dans la demande de certificat est la même que celle qui a été provisionnée en toute sécurité.
L’application envoie le reçu de clé et la demande de certificat, qui inclut la clé publique, à l’autorité d’inscription de certificat hébergée sur la batterie de serveurs Services ADFS (AD FS).
Après avoir reçu la demande de certificat, l’autorité d’inscription de certificat interroge Active Directory pour obtenir la liste des clés publiques inscrites dans msDS-KeyCredentialsLink.
E L’autorité d’inscription valide que la clé publique dans la demande de certificat correspond à une clé inscrite pour l’utilisateur.
Si la clé publique dans le certificat n’est pas trouvée dans la liste des clés publiques inscrites, elle valide ensuite la réception de la clé pour confirmer que la clé a été inscrite en toute sécurité auprès d’Azure.
Après avoir validé le reçu de clé ou la clé publique, l’autorité d’inscription signe la demande de certificat à l’aide de son certificat d’agent d’inscription.
F L’autorité d’inscription envoie la demande de certificat à l’autorité de certification émettrice de l’entreprise. L’autorité de certification valide que la demande de certificat est signée par un agent d’inscription valide et, en cas de réussite, émet un certificat et le retourne à l’autorité d’inscription qui retourne ensuite le certificat à l’application.
G L’application reçoit le certificat nouvellement émis et l’installe dans le magasin Personnel de l’utilisateur. Cela signale la fin de l’approvisionnement.

Important

L’inscription de certificat synchrone ne dépend pas de Microsoft Entra Connect pour synchroniser la clé publique de l’utilisateur afin d’émettre le certificat d’authentification Windows Hello Entreprise. Les utilisateurs peuvent se connecter à l’aide du certificat immédiatement après la fin de l’approvisionnement. Microsoft Entra Connect continue de synchroniser la clé publique avec Active Directory, mais n’apparaît pas dans ce flux.

Provisionnement dans un modèle de déploiement d’approbation de clé locale

Diagramme séquentiel du flux d’approvisionnement Windows Hello dans un modèle de déploiement d’approbation de clé locale.

Phase Description
A L’application d’approvisionnement hébergée dans l’hôte d’expérience cloud (CXH) commence l’approvisionnement en demandant un jeton d’accès pour le service EDRS (Enterprise Device Registration Service). L’application effectue la demande à l’aide du plug-in gestionnaire de compte web Microsoft Entra.
Dans un déploiement local, le plug-in envoie la demande de jeton au service STS local, par exemple Services ADFS. Le service STS local authentifie l’utilisateur et détermine si l’utilisateur doit effectuer un autre facteur d’authentification.
Les utilisateurs doivent fournir deux facteurs d’authentification. Dans cette phase, l’utilisateur a déjà fourni un facteur d’authentification, généralement le nom d’utilisateur et le mot de passe. Microsoft Entra serveur d’authentification multifacteur (ou un service non Microsoft MFA) fournit le deuxième facteur d’authentification.
Le serveur STS local émet un jeton DRS d’entreprise en cas d’authentification multifacteur réussie.
B Après avoir reçu un jeton d’accès EDRS, l’application détecte si l’appareil dispose d’un capteur compatible Windows Hello biométrique. Si l’application détecte un capteur biométrique, elle donne à l’utilisateur le choix d’inscrire la biométrie. Une fois l’inscription biométrique terminée ou ignorée, l’application exige que l’utilisateur crée un code confidentiel et le mouvement par défaut (et un mouvement de secours lorsqu’il est utilisé avec la biométrie). L’utilisateur fournit et confirme son code confidentiel. Ensuite, l’application demande une paire de clés Windows Hello Entreprise à partir du pool de clés de prégénération, qui inclut des données d’attestation. Il s’agit de la clé utilisateur (ukpub/ukpriv).
C L’application envoie le jeton EDRS, ukpub, les données d’attestation et les informations d’appareil à l’entreprise DRS pour l’inscription de la clé utilisateur. Enterprise DRS valide la revendication MFA reste à jour. Une fois la validation réussie, enterprise DRS localise l’objet de l’utilisateur dans Active Directory et écrit les informations clés dans un attribut à valeurs multiples. Les informations clés incluent une référence à l’appareil à partir duquel elles ont été créées. Le DRS d’entreprise retourne un ID de clé à l’application, qui représente la fin de l’inscription de clé utilisateur.

Provisionnement dans un modèle de déploiement d’approbation de certificat local

Diagramme de séquence du flux d’approvisionnement Windows Hello dans un modèle de déploiement d’approbation de certificat local.

Phase Description
A L’application d’approvisionnement hébergée dans l’hôte d’expérience cloud (CXH) commence l’approvisionnement en demandant un jeton d’accès pour le service EDRS (Enterprise Device Registration Service). L’application effectue la demande à l’aide du plug-in gestionnaire de compte web Microsoft Entra.
Dans un déploiement local, le plug-in envoie la demande de jeton au service STS local, par exemple Services ADFS. Le service STS local authentifie l’utilisateur et détermine si l’utilisateur doit effectuer un autre facteur d’authentification.
Les utilisateurs doivent fournir deux facteurs d’authentification. Dans cette phase, l’utilisateur a déjà fourni un facteur d’authentification, généralement le nom d’utilisateur et le mot de passe. Microsoft Entra serveur d’authentification multifacteur (ou un service non Microsoft MFA) fournit le deuxième facteur d’authentification.
Le serveur STS local émet un jeton DRS d’entreprise en cas d’authentification multifacteur réussie.
B Après avoir reçu un jeton d’accès EDRS, l’application détecte si l’appareil dispose d’un capteur compatible Windows Hello biométrique. Si l’application détecte un capteur biométrique, elle donne à l’utilisateur le choix d’inscrire la biométrie. Une fois l’inscription biométrique terminée ou ignorée, l’application exige que l’utilisateur crée un code confidentiel et le mouvement par défaut (et un mouvement de secours lorsqu’il est utilisé avec la biométrie). L’utilisateur fournit et confirme son code confidentiel. Ensuite, l’application demande une paire de clés Windows Hello Entreprise à partir du pool de clés de prégénération, qui inclut des données d’attestation. Il s’agit de la clé utilisateur (ukpub/ukpriv).
C L’application envoie le jeton EDRS, ukpub, les données d’attestation et les informations d’appareil à l’entreprise DRS pour l’inscription de la clé utilisateur. Enterprise DRS valide la revendication MFA reste à jour. Une fois la validation réussie, enterprise DRS localise l’objet de l’utilisateur dans Active Directory et écrit les informations clés dans un attribut à valeurs multiples. Les informations clés incluent une référence à l’appareil à partir duquel elles ont été créées. Le DRS d’entreprise retourne un ID de clé à l’application, qui représente la fin de l’inscription de clé utilisateur.
D La partie demande de certificat de l’approvisionnement commence une fois que l’application a reçu une réponse réussie de l’inscription de clé. L’application crée une demande de certificat PKCS#10. La clé utilisée dans la demande de certificat est la même que celle qui a été provisionnée en toute sécurité.
L’application envoie la demande de certificat, qui inclut la clé publique, à l’autorité d’inscription de certificat hébergée sur la batterie de serveurs Services ADFS (AD FS).
Après avoir reçu la demande de certificat, l’autorité d’inscription de certificat interroge Active Directory pour obtenir la liste des clés publiques inscrites dans msDS-KeyCredentialsLink.
E L’autorité d’inscription valide que la clé publique dans la demande de certificat correspond à une clé inscrite pour l’utilisateur.
Après avoir validé la clé publique, l’autorité d’inscription signe la demande de certificat à l’aide de son certificat d’agent d’inscription.
F L’autorité d’inscription envoie la demande de certificat à l’autorité de certification émettrice de l’entreprise. L’autorité de certification valide que la demande de certificat est signée par un agent d’inscription valide et, en cas de réussite, émet un certificat et le retourne à l’autorité d’inscription qui retourne ensuite le certificat à l’application.
G L’application reçoit le certificat nouvellement émis et l’installe dans le magasin Personnel de l’utilisateur. Cela signale la fin de l’approvisionnement.