Authentification Windows Hello Entreprise
Windows Hello Entreprise’authentification est une authentification à deux facteurs sans mot de passe. L’authentification avec Windows Hello Entreprise offre une expérience de connexion pratique qui authentifie l’utilisateur auprès des ressources Microsoft Entra ID et Active Directory.
Microsoft Entra appareils joints s’authentifient auprès de Microsoft Entra ID lors de la connexion et peuvent éventuellement s’authentifier auprès d’Active Directory. Microsoft Entra appareils joints hybrides s’authentifient auprès d’Active Directory lors de la connexion et s’authentifient auprès de Microsoft Entra ID en arrière-plan.
Microsoft Entra joindre l’authentification à Microsoft Entra ID
Remarque
Tous les appareils joints Microsoft Entra s’authentifient auprès de Windows Hello Entreprise pour Microsoft Entra ID de la même façon. Le type d’approbation Windows Hello Entreprise affecte uniquement la façon dont l’appareil s’authentifie auprès d’AD local.
| Phase | Description |
|---|---|
| A | L’authentification commence lorsque l’utilisateur ferme l’écran de verrouillage, ce qui déclenche Winlogon pour afficher le fournisseur d’informations d’identification Windows Hello Entreprise. L’utilisateur fournit son mouvement Windows Hello (code confidentiel ou biométrie). Le fournisseur d’informations d’identification empaquette ces informations d’identification et les retourne à Winlogon. Winlogon transmet les informations d’identification collectées à LSASS. LSASS transmet les informations d’identification collectées au fournisseur de support de sécurité d’authentification cloud, appelé fournisseur d’AP cloud. |
| B | Le fournisseur d’API cloud demande une valeur nonce à Microsoft Entra ID. Microsoft Entra ID retourne une valeur nonce. Le fournisseur Cloud AP signe le nonce à l’aide de la clé privée de l’utilisateur et retourne le nonce signé à l’Microsoft Entra ID. |
| C | Microsoft Entra ID valide le nonce signé à l’aide de la clé publique inscrite en toute sécurité de l’utilisateur par rapport à la signature nonce. Microsoft Entra ID valide ensuite le nonce signé retourné et crée un PRT avec la clé de session qui est chiffré à la clé de transport de l’appareil et le retourne au fournisseur d’accès cloud. |
| D | Le fournisseur d’API cloud reçoit le PRT chiffré avec une clé de session. À l’aide de la clé de transport privée de l’appareil, le fournisseur d’api cloud déchiffre la clé de session et protège la clé de session à l’aide du module TPM de l’appareil. |
| E | Le fournisseur d’API cloud retourne une réponse d’authentification réussie à LSASS. LSASS met en cache le PRT et informe Winlogon de la réussite de l’authentification. Winlogon crée une session d’ouverture de session, charge le profil de l’utilisateur et démarre explorer.exe. |
Microsoft Entra joindre l’authentification à Active Directory à l’aide de l’approbation Kerberos cloud
| Phase | Description |
|---|---|
| A | L’authentification auprès d’Active Directory à partir d’un appareil joint Microsoft Entra commence par la première tentative de l’utilisateur d’utiliser une ressource qui a besoin d’une authentification Kerberos. Le fournisseur de support de sécurité Kerberos, hébergé dans LSASS, utilise les métadonnées de la clé Windows Hello Entreprise pour obtenir un indicateur du domaine de l’utilisateur. À l’aide de l’indicateur, le fournisseur utilise le service DClocator pour localiser un contrôleur de domaine. |
| B | Après avoir localisé un contrôleur de domaine, le fournisseur Kerberos envoie au contrôleur de domaine un TGT partiel qu’il a reçu de Microsoft Entra ID d’une authentification Microsoft Entra précédente. Le TGT partiel contient uniquement le SID de l’utilisateur et il est signé par Microsoft Entra Kerberos. Le contrôleur de domaine vérifie que le TGT partiel est valide. En cas de réussite, le KDC retourne un TGT au client. |
Microsoft Entra joindre l’authentification à Active Directory à l’aide d’une clé
| Phase | Description |
|---|---|
| A | L’authentification auprès d’Active Directory à partir d’un appareil joint Microsoft Entra commence par la première tentative de l’utilisateur d’utiliser une ressource qui a besoin d’une authentification Kerberos. Le fournisseur de support de sécurité Kerberos, hébergé dans LSASS, utilise les métadonnées de la clé Windows Hello Entreprise pour obtenir un indicateur du domaine de l’utilisateur. À l’aide de l’indicateur, le fournisseur utilise le service DClocator pour localiser un contrôleur de domaine. Une fois que le fournisseur a localisé un contrôleur de domaine, il utilise la clé privée pour signer les données de pré-authentification Kerberos. |
| B | Le fournisseur Kerberos envoie les données de pré-authentification signées et sa clé publique (sous la forme d’un certificat auto-signé) au service Centre de distribution de clés (KDC) exécuté sur le contrôleur de domaine sous la forme d’un KERB_AS_REQ. Le contrôleur de domaine détermine que le certificat est un certificat auto-signé. Il récupère la clé publique à partir du certificat inclus dans le KERB_AS_REQ et recherche la clé publique dans Active Directory. Il valide l’UPN pour la demande d’authentification correspond à l’UPN inscrit dans Active Directory et valide les données de pré-authentification signées à l’aide de la clé publique d’Active Directory. En cas de réussite, le KDC retourne un TGT au client avec son certificat dans un KERB_AS_REP. |
| C | Le fournisseur Kerberos garantit qu’il peut approuver la réponse du contrôleur de domaine. Tout d’abord, il garantit que le certificat KDC est lié à un certificat racine approuvé par l’appareil. Ensuite, il garantit que le certificat est dans sa période de validité et qu’il n’a pas été révoqué. Le fournisseur Kerberos vérifie ensuite que le certificat dispose de l’authentification KDC et que l’autre nom de l’objet répertorié dans le certificat du KDC correspond au nom de domaine auquel l’utilisateur s’authentifie. Après avoir passé ce critère, Kerberos retourne le TGT à LSASS, où il est mis en cache et utilisé pour les demandes de ticket de service suivantes. |
Remarque
Vous pouvez avoir un domaine local fédéré avec Microsoft Entra ID. Une fois que vous avez correctement approvisionné Windows Hello Entreprise code confidentiel/bio sur l’appareil joint Microsoft Entra, toute connexion ultérieure de Windows Hello Entreprise (PIN/Bio) s’authentifiera directement auprès de Microsoft Entra ID pour obtenir PRT et déclencher l’authentification auprès de votre contrôleur de domaine (si los to DC est disponible) pour obtenir Kerberos. Il n’utilise plus AD FS pour s’authentifier pour Windows Hello Entreprise connexions.
Microsoft Entra joindre l’authentification à Active Directory à l’aide d’un certificat
| Phase | Description |
|---|---|
| A | L’authentification auprès d’Active Directory à partir d’un appareil joint Microsoft Entra commence par la première tentative de l’utilisateur d’utiliser une ressource qui a besoin d’une authentification Kerberos. Le fournisseur de support de sécurité Kerberos, hébergé dans LSASS, utilise les informations du certificat pour obtenir un indicateur du domaine de l’utilisateur. Kerberos peut utiliser le nom unique de l’utilisateur trouvé dans l’objet du certificat, ou il peut utiliser le nom d’utilisateur principal de l’utilisateur trouvé dans l’autre nom d’objet du certificat. À l’aide de l’indicateur, le fournisseur utilise le service DClocator pour localiser un contrôleur de domaine. Une fois que le fournisseur a localisé un contrôleur de domaine actif, il utilise la clé privée pour signer les données de pré-authentification Kerberos. |
| B | Le fournisseur Kerberos envoie les données de pré-authentification signées et le certificat de l’utilisateur, qui inclut la clé publique, au service Centre de distribution de clés (KDC) exécuté sur le contrôleur de domaine sous la forme d’un KERB_AS_REQ. Le contrôleur de domaine détermine que le certificat n’est pas un certificat auto-signé. Le contrôleur de domaine garantit que les chaînes de certificats vers le certificat racine approuvé, sont dans leur période de validité, peuvent être utilisées pour l’authentification et n’ont pas été révoquées. Il récupère la clé publique et l’UPN à partir du certificat inclus dans le KERB_AS_REQ et recherche l’UPN dans Active Directory. Il valide les données de pré-authentification signées à l’aide de la clé publique du certificat. En cas de réussite, le KDC retourne un TGT au client avec son certificat dans un KERB_AS_REP. |
| C | Le fournisseur Kerberos garantit qu’il peut approuver la réponse du contrôleur de domaine. Tout d’abord, il garantit que le certificat KDC est lié à un certificat racine approuvé par l’appareil. Ensuite, il garantit que le certificat est dans sa période de validité et qu’il n’a pas été révoqué. Le fournisseur Kerberos vérifie ensuite que le certificat dispose de l’authentification KDC et que l’autre nom de l’objet répertorié dans le certificat du KDC correspond au nom de domaine auquel l’utilisateur s’authentifie. Après avoir passé ce critère, Kerberos retourne le TGT à LSASS, où il est mis en cache et utilisé pour les demandes de ticket de service suivantes. |
Remarque
Vous pouvez avoir un domaine local fédéré avec Microsoft Entra ID. Une fois que vous avez correctement provisionné Windows Hello Entreprise code confidentiel/bio, toute connexion future de Windows Hello Entreprise (PIN/Bio) s’authentifie directement auprès de Microsoft Entra ID pour obtenir le PRT, ainsi que l’authentification auprès de votre contrôleur de domaine (si LOS à DC est disponible) pour obtenir Kerberos comme mentionné ci-dessus auparavant. La fédération AD FS est utilisée uniquement lorsque des appels PRT d’entreprise sont placés à partir du client. L’écriture différée de l’appareil doit être activée pour obtenir « Enterprise PRT » à partir de votre fédération.
Microsoft Entra l’authentification de jointure hybride à l’aide de l’approbation Kerberos cloud
| Phase | Description |
|---|---|
| A | L’authentification commence lorsque l’utilisateur ferme l’écran de verrouillage, ce qui déclenche Winlogon pour afficher le fournisseur d’informations d’identification Windows Hello Entreprise. L’utilisateur fournit son mouvement Windows Hello (code confidentiel ou biométrie). Le fournisseur d’informations d’identification empaquette ces informations d’identification et les retourne à Winlogon. Winlogon transmet les informations d’identification collectées à LSASS. Les requêtes LSASS Windows Hello Entreprise stratégie pour case activée si l’approbation Kerberos cloud est activée. Si l’approbation Kerberos cloud est activée, LSASS transmet les informations d’identification collectées au fournisseur de prise en charge de la sécurité de l’authentification cloud, ou cloud AP. L’AP cloud demande une valeur nonce à Microsoft Entra ID. Microsoft Entra ID retourne une valeur nonce. |
| B | Cloud AP signe le nonce à l’aide de la clé privée de l’utilisateur et retourne la nonce signée à Microsoft Entra ID. |
| C | Microsoft Entra ID valide le nonce signé à l’aide de la clé publique inscrite en toute sécurité de l’utilisateur par rapport à la signature nonce. Après avoir validé la signature, Microsoft Entra ID valide le nonce signé retourné. Après avoir validé la valeur nonce, Microsoft Entra ID crée un PRT avec une clé de session chiffrée sur la clé de transport de l’appareil et crée un TGT partiel à partir de Microsoft Entra Kerberos et le retourne à Cloud AP. |
| D | Cloud AP reçoit le PRT chiffré avec une clé de session. À l’aide de la clé de transport privée de l’appareil, Cloud AP déchiffre la clé de session et protège la clé de session à l’aide du module TPM de l’appareil (si disponible). L’AP cloud retourne une réponse d’authentification réussie à LSASS. LSASS met en cache le PRT et le TGT partiel. |
| E | Le fournisseur de support de sécurité Kerberos, hébergé dans LSASS, utilise les métadonnées de la clé Windows Hello Entreprise pour obtenir un indicateur du domaine de l’utilisateur. À l’aide de l’indicateur, le fournisseur utilise le service DClocator pour localiser un contrôleur de domaine. Après avoir localisé un contrôleur de domaine actif, le fournisseur Kerberos envoie le TGT partiel qu’il a reçu de Microsoft Entra ID au contrôleur de domaine. Le TGT partiel contient uniquement le SID utilisateur et est signé par Microsoft Entra Kerberos. Le contrôleur de domaine vérifie que le TGT partiel est valide. En cas de réussite, le KDC retourne un TGT au client. Kerberos retourne le TGT à LSASS, où il est mis en cache et utilisé pour les demandes de ticket de service suivantes. LSASS informe Winlogon de la réussite de l’authentification. Winlogon crée une session d’ouverture de session, charge le profil de l’utilisateur et démarre explorer.exe. |
Microsoft Entra l’authentification de jointure hybride à l’aide d’une clé
| Phase | Description |
|---|---|
| A | L’authentification commence lorsque l’utilisateur ferme l’écran de verrouillage, ce qui déclenche Winlogon pour afficher le fournisseur d’informations d’identification Windows Hello Entreprise. L’utilisateur fournit son mouvement Windows Hello (code confidentiel ou biométrie). Le fournisseur d’informations d’identification empaquette ces informations d’identification et les retourne à Winlogon. Winlogon transmet les informations d’identification collectées à LSASS. LSASS transmet les informations d’identification collectées au fournisseur de support de sécurité Kerberos. Le fournisseur Kerberos obtient des indicateurs de domaine à partir de la station de travail jointe au domaine pour localiser un contrôleur de domaine pour l’utilisateur. |
| B | Le fournisseur Kerberos envoie les données de pré-authentification signées et la clé publique de l’utilisateur (sous la forme d’un certificat auto-signé) au service centre de distribution de clés (KDC) exécuté sur le contrôleur de domaine sous la forme d’un KERB_AS_REQ. Le contrôleur de domaine détermine que le certificat est un certificat auto-signé. Il récupère la clé publique à partir du certificat inclus dans le KERB_AS_REQ et recherche la clé publique dans Active Directory. Il valide l’UPN pour la demande d’authentification correspond à l’UPN inscrit dans Active Directory et valide les données de pré-authentification signées à l’aide de la clé publique d’Active Directory. En cas de réussite, le KDC retourne un TGT au client avec son certificat dans un KERB_AS_REP. |
| C | Le fournisseur Kerberos garantit qu’il peut approuver la réponse du contrôleur de domaine. Tout d’abord, il garantit que le certificat KDC est lié à un certificat racine approuvé par l’appareil. Ensuite, il garantit que le certificat est dans sa période de validité et qu’il n’a pas été révoqué. Le fournisseur Kerberos vérifie ensuite que le certificat dispose de l’authentification KDC et que l’autre nom de l’objet répertorié dans le certificat du KDC correspond au nom de domaine auquel l’utilisateur s’authentifie. |
| D | Après avoir passé ce critère, Kerberos retourne le TGT à LSASS, où il est mis en cache et utilisé pour les demandes de ticket de service suivantes. |
| E | LSASS informe Winlogon de la réussite de l’authentification. Winlogon crée une session d’ouverture de session, charge le profil de l’utilisateur et démarre explorer.exe. |
| F | Pendant que Windows charge le bureau de l’utilisateur, LSASS transmet les informations d’identification collectées au fournisseur de prise en charge de la sécurité de l’authentification cloud, appelé fournisseur d’api cloud. Le fournisseur d’API cloud demande une valeur nonce à Microsoft Entra ID. Microsoft Entra ID retourne une valeur nonce. |
| G | Le fournisseur Cloud AP signe le nonce à l’aide de la clé privée de l’utilisateur et retourne le nonce signé à l’Microsoft Entra ID. Microsoft Entra ID valide le nonce signé à l’aide de la clé publique inscrite en toute sécurité de l’utilisateur par rapport à la signature nonce. Après avoir validé la signature, Microsoft Entra ID valide le nonce signé retourné. Après avoir validé la valeur nonce, Microsoft Entra ID crée un PRT avec une clé de session chiffrée sur la clé de transport de l’appareil et le retourne au fournisseur d’accès cloud. Le fournisseur d’API cloud reçoit le PRT chiffré avec une clé de session. À l’aide de la clé de transport privée de l’appareil, le fournisseur d’api cloud déchiffre la clé de session et protège la clé de session à l’aide du module TPM de l’appareil. Le fournisseur d’API cloud retourne une réponse d’authentification réussie à LSASS. LSASS met en cache le PRT. |
Important
Dans le modèle de déploiement ci-dessus, un utilisateur nouvellement provisionné ne peut pas se connecter à l’aide de Windows Hello Entreprise tant que (a) Microsoft Entra Connect synchronise correctement la clé publique avec le Active Directory local et (b) que l’appareil dispose d’une ligne de vue sur le contrôleur de domaine pour la première fois.
Microsoft Entra l’authentification de jointure hybride à l’aide d’un certificat
| Phase | Description |
|---|---|
| A | L’authentification commence lorsque l’utilisateur ferme l’écran de verrouillage, ce qui déclenche Winlogon pour afficher le fournisseur d’informations d’identification Windows Hello Entreprise. L’utilisateur fournit son mouvement Windows Hello (code confidentiel ou biométrie). Le fournisseur d’informations d’identification empaquette ces informations d’identification et les retourne à Winlogon. Winlogon transmet les informations d’identification collectées à LSASS. LSASS transmet les informations d’identification collectées au fournisseur de support de sécurité Kerberos. Le fournisseur Kerberos obtient des indicateurs de domaine à partir de la station de travail jointe au domaine pour localiser un contrôleur de domaine pour l’utilisateur. |
| B | Le fournisseur Kerberos envoie les données de pré-authentification signées et le certificat de l’utilisateur, qui inclut la clé publique, au service Centre de distribution de clés (KDC) exécuté sur le contrôleur de domaine sous la forme d’un KERB_AS_REQ. Le contrôleur de domaine détermine que le certificat n’est pas un certificat auto-signé. Le contrôleur de domaine garantit que les chaînes de certificats vers le certificat racine approuvé, sont dans leur période de validité, peuvent être utilisées pour l’authentification et n’ont pas été révoquées. Il récupère la clé publique et l’UPN à partir du certificat inclus dans le KERB_AS_REQ et recherche l’UPN dans Active Directory. Il valide les données de pré-authentification signées à l’aide de la clé publique du certificat. En cas de réussite, le KDC retourne un TGT au client avec son certificat dans un KERB_AS_REP. |
| C | Le fournisseur Kerberos garantit qu’il peut approuver la réponse du contrôleur de domaine. Tout d’abord, il garantit que le certificat KDC est lié à un certificat racine approuvé par l’appareil. Ensuite, il garantit que le certificat est dans sa période de validité et qu’il n’a pas été révoqué. Le fournisseur Kerberos vérifie ensuite que le certificat dispose de l’authentification KDC et que l’autre nom de l’objet répertorié dans le certificat du KDC correspond au nom de domaine auquel l’utilisateur s’authentifie. |
| D | Après avoir passé ce critère, Kerberos retourne le TGT à LSASS, où il est mis en cache et utilisé pour les demandes de ticket de service suivantes. |
| E | LSASS informe Winlogon de la réussite de l’authentification. Winlogon crée une session d’ouverture de session, charge le profil de l’utilisateur et démarre explorer.exe. |
| F | Pendant que Windows charge le bureau de l’utilisateur, LSASS transmet les informations d’identification collectées au fournisseur de prise en charge de la sécurité de l’authentification cloud, appelé fournisseur d’api cloud. Le fournisseur d’API cloud demande une valeur nonce à Microsoft Entra ID. Microsoft Entra ID retourne une valeur nonce. |
| G | Le fournisseur Cloud AP signe le nonce à l’aide de la clé privée de l’utilisateur et retourne le nonce signé à l’Microsoft Entra ID. Microsoft Entra ID valide le nonce signé à l’aide de la clé publique inscrite en toute sécurité de l’utilisateur par rapport à la signature nonce. Après avoir validé la signature, Microsoft Entra ID valide le nonce signé retourné. Après avoir validé la valeur nonce, Microsoft Entra ID crée un PRT avec une clé de session chiffrée sur la clé de transport de l’appareil et le retourne au fournisseur d’accès cloud. Le fournisseur d’API cloud reçoit le PRT chiffré avec une clé de session. À l’aide de la clé de transport privée de l’appareil, le fournisseur d’api cloud déchiffre la clé de session et protège la clé de session à l’aide du module TPM de l’appareil. Le fournisseur d’API cloud retourne une réponse d’authentification réussie à LSASS. LSASS met en cache le PRT. |
Important
Dans ce modèle de déploiement, un utilisateur nouvellement provisionné ne peut pas se connecter à l’aide de Windows Hello Entreprise, sauf si l’appareil a une ligne de vue sur le contrôleur de domaine.