Partager via

Planifier un déploiement Windows Hello Entreprise

Ce guide de planification vous permet de comprendre les différentes topologies, les différentes architectures et les différents composants qui englobent une infrastructure Windows Hello Entreprise.

Ce guide explique le rôle de chaque composant dans Windows Hello Entreprise et l’impact de certaines décisions de déploiement sur les autres aspects de l’infrastructure.

Astuce

Si vous avez un locataire d’ID Microsoft Entra, vous pouvez utiliser notre Assistant sans mot de passe interactif en ligne, qui présente les mêmes choix au lieu d’utiliser notre guide manuel ci-dessous. L’Assistant sans mot de passe est disponible dans le Centre d’administration Microsoft 365.

Utilisation de ce guide

De nombreuses options sont disponibles pour le déploiement de Windows Hello Entreprise, garantissant ainsi la compatibilité avec différentes infrastructures organisationnelles. Bien que le processus de déploiement puisse sembler complexe, la plupart des organisations constatent qu’elles ont déjà implémenté l’infrastructure nécessaire. Il est important de noter que Windows Hello Entreprise est un système distribué qui nécessite une planification appropriée au sein de plusieurs équipes au sein d’une organisation.

Ce guide vise à simplifier le processus de déploiement en vous aidant à prendre des décisions éclairées sur chaque aspect de votre déploiement Windows Hello Entreprise. Il fournit des informations sur les options disponibles et vous aide à sélectionner l’approche de déploiement qui convient le mieux à votre environnement.

Procédure à suivre

Lisez ce document et enregistrez vos décisions. Lorsque vous avez terminé, vous devez disposer de toutes les informations nécessaires pour évaluer les options disponibles et déterminer les exigences pour votre déploiement de Windows Hello Entreprise.

Il existe sept domaines principaux à prendre en compte lors de la planification d’un déploiement de Windows Hello Entreprise :

Options de déploiement

L’objectif de Windows Hello Entreprise est de permettre des déploiements pour toutes les organisations, quelle que soit leur taille ou leur situation. Pour fournir ce type de déploiement granulaire, Windows Hello Entreprise propose un choix varié d'options de déploiement.

Modèles de déploiement

Il est fondamentalement important de comprendre quel modèle de déploiement utiliser pour un déploiement réussi. Certains aspects du déploiement ont peut-être déjà été décidés pour vous en fonction de votre infrastructure actuelle.

Vous pouvez choisir trois modèles de déploiement :

Modèle de déploiement Description
🔲 Cloud uniquement Pour les organisations qui ont uniquement des identités cloud et n’accèdent pas aux ressources locales. Ces organisations joignent généralement leurs appareils au cloud et utilisent exclusivement des ressources dans le cloud telles que SharePoint Online, OneDrive et d’autres. En outre, étant donné que les utilisateurs n’utilisent pas de ressources locales, ils n’ont pas besoin de certificats pour des éléments tels que vpn, car tout ce dont ils ont besoin est hébergé dans des services cloud.
🔲 Hybride Pour les organisations dont les identités sont synchronisées entre Active Directory et l’ID Microsoft Entra. Ces organisations utilisent des applications inscrites dans l’ID Microsoft Entra et souhaitent une expérience d’authentification unique (SSO) pour les ressources locales et Microsoft Entra.
🔲 Local Pour les organisations qui n’ont pas d’identités cloud ou qui utilisent des applications hébergées dans l’ID Microsoft Entra. Ces organisations utilisent des applications locales, intégrées à Active Directory, et souhaitent une expérience utilisateur d’authentification unique lors de l’accès à celles-ci.

Remarque

  • Le principal cas d’utilisation du déploiement local concerne les « environnements administratifs de sécurité renforcée », également appelés « forêts rouges ».
  • La migration d’un déploiement local vers un déploiement hybride nécessite un redéploiement

Types d’approbations

Le type d’approbation d’un déploiement définit la façon dont les clients Windows Hello Entreprise s’authentifient auprès d’Active Directory. Le type d’approbation n’affecte pas l’authentification auprès de l’ID Microsoft Entra. Pour cette raison, le type d’approbation n’est pas applicable à un modèle de déploiement cloud uniquement.

L’authentification Windows Hello Entreprise auprès de l’ID Microsoft Entra utilise toujours la clé, et non un certificat (à l’exception de l’authentification par carte à puce dans un environnement fédéré).

Le type d’approbation détermine si vous émettez des certificats d’authentification à vos utilisateurs. Un modèle d’approbation n’est pas plus sécurisé que l’autre.

Le déploiement de certificats pour les utilisateurs et les contrôleurs de domaine nécessite davantage de configuration et d’infrastructure, ce qui peut également être un facteur à prendre en compte dans votre décision. L’infrastructure supplémentaire nécessaire pour les déploiements d’approbation de certificats inclut une autorité d’enregistrement de certificat. Dans un environnement fédéré, vous devez activer l’option Réécriture de l’appareil dans Microsoft Entra Connect.

Vous pouvez choisir trois types d’approbation :

Type d’approbation Description
🔲 Cloud Kerberos Les utilisateurs s’authentifient auprès d’Active Directory en demandant un TGT à l’ID Microsoft Entra, à l’aide de Microsoft Entra Kerberos. Les contrôleurs de domaine locaux sont toujours responsables des tickets de service Kerberos et de l’autorisation. L’approbation Kerberos cloud utilise la même infrastructure requise pour la connexion par clé de sécurité FIDO2, et elle peut être utilisée pour les déploiements Windows Hello Entreprise nouveaux ou existants.
🔲 Clé Les utilisateurs s’authentifient auprès de l’Active Directory local à l’aide d’une clé liée à l’appareil (matériel ou logiciel) créée pendant l’expérience d’approvisionnement Windows Hello. Il nécessite de distribuer des certificats aux contrôleurs de domaine.
🔲 Certificat Le type d’approbation de certificat émet des certificats d’authentification pour les utilisateurs. Les utilisateurs s’authentifient à l’aide d’un certificat demandé à l’aide d’une clé liée à l’appareil (matériel ou logiciel) créée pendant l’expérience d’approvisionnement Windows Hello.

L’approbation de clé et l’approbation de certificat utilisent Kerberos basé sur l’authentification par certificat lors de la demande de tickets-granting-tickets Kerberos (TGT) pour l’authentification locale. Ce type d’authentification nécessite une infrastructure à clé publique pour les certificats DC et des certificats d’utilisateur final pour l’approbation de certificat.

L’objectif de l’approbation Kerberos cloud Windows Hello Entreprise est de fournir une expérience de déploiement plus simple par rapport aux autres types d’approbation :

  • Il n’est pas nécessaire de déployer une infrastructure à clé publique (PKI) ou de modifier une infrastructure à clé publique existante
  • Il n’est pas nécessaire de synchroniser les clés publiques entre l’ID Microsoft Entra et Active Directory pour que les utilisateurs puissent accéder aux ressources locales. Il n’y a aucun délai entre l’approvisionnement de Windows Hello Entreprise de l’utilisateur et la possibilité de s’authentifier auprès d’Active Directory
  • La connexion par clé de sécurité FIDO2 peut être déployée avec une configuration supplémentaire minimale

Astuce

L’approbation Kerberos cloud Windows Hello Entreprise est le modèle de déploiement recommandé par rapport au modèle d’approbation de clé. Il s’agit également du modèle de déploiement préféré si vous n’avez pas besoin de prendre en charge les scénarios d’authentification par certificat.

L’approbation Kerberos cloud nécessite le déploiement de Microsoft Entra Kerberos. Pour plus d’informations sur la façon dont Microsoft Entra Kerberos permet l’accès aux ressources locales, consultez Activation de la connexion par clé de sécurité sans mot de passe aux ressources locales.

Configuration requise pour l’infrastructure à clé publique

L’approbation Kerberos cloud est la seule option de déploiement hybride qui ne nécessite pas le déploiement de certificats. Les autres modèles hybrides et locaux dépendent d’une infrastructure à clé publique d’entreprise comme ancre d’approbation pour l’authentification :

  • Les contrôleurs de domaine pour les déploiements hybrides et locaux ont besoin d’un certificat pour que les appareils Windows approuvent le contrôleur de domaine comme légitime
  • Les déploiements utilisant le type d’approbation de certificat nécessitent une infrastructure à clé publique d’entreprise et une autorité d’inscription de certificat (CRA) pour émettre des certificats d’authentification aux utilisateurs. AD FS est utilisé comme cra
  • Les déploiements hybrides peuvent avoir besoin d’émettre des certificats VPN aux utilisateurs pour activer la connectivité des ressources locales
Modèle de déploiement Type d’approbation PKI obligatoire ?
🔲 Cloud uniquement Non applicable non
🔲 Hybride Cloud Kerberos non
🔲 Hybride Clé oui
🔲 Hybride Certificat oui
🔲 Local Clé oui
🔲 Local Certificat oui

Authentification auprès de l’ID Microsoft Entra

Les utilisateurs peuvent s’authentifier auprès de l’ID Microsoft Entra à l’aide de l’authentification fédérée ou de l’authentification cloud (non fédérée). Les exigences varient en fonction du type d’approbation :

Modèle de déploiement Type d’approbation Authentification auprès de l’ID Microsoft Entra Conditions préalables
🔲 Cloud uniquement Non applicable Authentification cloud Non applicable
🔲 Cloud uniquement Non applicable Authentification fédérée Service de fédération non-Microsoft
🔲 Hybride Approbation Kerberos cloud Authentification cloud Synchronisation de hachage de mot de passe (PHS) ou authentification directe (PTA)
🔲 Hybride Approbation Kerberos cloud Authentification fédérée Service de fédération AD FS ou non-Microsoft
🔲 Hybride Approbation de clé Authentification cloud Synchronisation de hachage de mot de passe (PHS) ou authentification directe (PTA)
🔲 Hybride Approbation de clé Authentification fédérée Service de fédération AD FS ou non-Microsoft
🔲 Hybride Approbation de certificat Authentification fédérée Ce modèle de déploiement ne prend pas en charge pTA ou PHS. Active Directory doit être fédéré avec l’ID Microsoft Entra à l’aide d’AD FS

Pour en savoir plus :

Informations techniques de référence sur l’inscription de l’appareil

Pour les déploiements locaux, le serveur exécutant le rôle Ad FS (Active Directory Federation Services) est responsable de l’inscription de l’appareil. Pour les déploiements cloud uniquement et hybrides, les appareils doivent s’inscrire dans l’ID Microsoft Entra.

Modèle de déploiement Type de jointure pris en charge Fournisseur de services d’inscription d’appareil
Cloud uniquement Microsoft Entra joint
Microsoft Entra inscrit		 Microsoft Entra ID
Hybride Microsoft Entra joint
Jointure hybride Microsoft Entra
Microsoft Entra inscrit		 Microsoft Entra ID
Local Jointure à un domaine Active Directory Synchronisation complète AD

Important

Pour obtenir des conseils sur la jointure hybride Microsoft Entra , consultez Planifier votre implémentation de jointure hybride Microsoft Entra.

Authentification multifacteur

L’objectif de Windows Hello Entreprise est d’éloigner les organisations des mots de passe en leur fournissant des informations d’identification fortes qui facilitent l’authentification à deux facteurs. L’expérience d’approvisionnement intégrée accepte les informations d’identification faibles de l’utilisateur (nom d’utilisateur et mot de passe) comme première authentification factorielle. Toutefois, l’utilisateur doit fournir un deuxième facteur d’authentification avant que Windows provisionne des informations d’identification fortes :

  • Pour les déploiements cloud uniquement et hybrides, il existe différents choix pour l’authentification multifacteur, notamment Microsoft Entra MFA
  • Les déploiements locaux doivent utiliser une option multifacteur qui peut s’intégrer en tant qu’adaptateur multifacteur AD FS. Les organisations peuvent choisir parmi des options non-Microsoft qui offrent un adaptateur MFA AD FS. Pour plus d’informations, consultez Méthodes d’authentification supplémentaires Microsoft et non-Microsoft

Important

Depuis le 1er juillet 2019, Microsoft ne propose pas de serveur MFA pour les nouveaux déploiements. Les nouveaux déploiements qui nécessitent une authentification multifacteur doivent utiliser l’authentification multifacteur Microsoft Entra basée sur le cloud.

À compter du 30 septembre 2024, les déploiements de serveurs Azure Multi-Factor Authentication ne serviront plus les requêtes MFA. Pour garantir des services d’authentification ininterrompus et rester dans un état pris en charge, les organisations doivent migrer les données d’authentification de leurs utilisateurs vers l’authentification azure MFA basée sur le cloud.

Modèle de déploiement Options de l’authentification multifacteur
🔲 Cloud uniquement Microsoft Entra MFA
🔲 Cloud uniquement Authentification multifacteur non-Microsoft, via une méthode d’authentification externe dans l’ID ou la fédération Microsoft Entra
🔲 Hybride Microsoft Entra MFA
🔲 Hybride Authentification multifacteur non-Microsoft, via une méthode d’authentification externe dans l’ID ou la fédération Microsoft Entra
🔲 Local Adaptateur AD FS MFA

Pour plus d'informations :

Authentification multifacteur et authentification fédérée

Il est possible pour les domaines fédérés de configurer l’indicateur FederatedIdpMfaBehavior . L’indicateur indique à l’ID Microsoft Entra d’accepter, d’appliquer ou de rejeter le défi MFA du fournisseur d’identité fédéré. Pour plus d’informations, consultez Valeurs federatedIdpMfaBehavior. Pour vérifier ce paramètre, utilisez la commande PowerShell suivante :

Connect-MgGraph
$DomainId = "<your federated domain name>"
Get-MgDomainFederationConfiguration -DomainId $DomainId |fl

Pour rejeter la revendication MFA du fournisseur d’identité fédéré, utilisez la commande suivante. Cette modification a un impact sur tous les scénarios d’authentification multifacteur pour le domaine fédéré :

Update-MgDomainFederationConfiguration -DomainId $DomainId -FederatedIdpMfaBehavior rejectMfaByFederatedIdp

Si vous configurez l’indicateur avec la valeur acceptIfMfaDoneByFederatedIdp (par défaut) ou enforceMfaByFederatedIdp, vous devez vérifier que votre fournisseur d’identité fédéré est correctement configuré et fonctionne avec l’adaptateur et le fournisseur MFA utilisés par votre fournisseur d’identité.

Inscription de clé

L’expérience d’approvisionnement intégrée de Windows Hello Entreprise crée une paire de clés asymétriques liée à l’appareil en tant qu’informations d’identification de l’utilisateur. La clé privée est protégée par les modules de sécurité de l’appareil. Les informations d’identification sont une clé utilisateur, et non une clé d’appareil. L’expérience d’approvisionnement inscrit la clé publique de l’utilisateur auprès du fournisseur d’identité :

Modèle de déploiement Fournisseur de services d’inscription de clé
Cloud uniquement Microsoft Entra ID
Hybride Microsoft Entra ID
Local Synchronisation complète AD

Synchronisation d'annuaires

Toutefois, les déploiements hybrides et locaux utilisent la synchronisation d’annuaires, chacun à des fins différentes :

  • Les déploiements hybrides utilisent Microsoft Entra Connect Sync pour synchroniser les identités Active Directory (utilisateurs et appareils) ou les informations d’identification entre eux et l’ID Microsoft Entra. Pendant le processus d’approvisionnement de Windows Hello Entreprise, les utilisateurs inscrivent la partie publique de leurs informations d’identification Windows Hello Entreprise avec l’ID Microsoft Entra. Microsoft Entra Connect Sync synchronise la clé publique Windows Hello Entreprise avec Active Directory. Cette synchronisation permet l’authentification unique vers l’ID Microsoft Entra et ses composants fédérés.

    Important

    Windows Hello Entreprise est lié entre un utilisateur et un appareil. L’objet utilisateur et l’objet d’appareil doivent être synchronisés entre l’ID Microsoft Entra et Active Directory.

  • Les déploiements locaux utilisent la synchronisation d’annuaires pour importer des utilisateurs d’Active Directory vers le serveur Azure MFA, qui envoie des données au service cloud MFA pour effectuer la vérification
Modèle de déploiement Options de synchronisation d’annuaires
Cloud uniquement Non applicable
Hybride Microsoft Entra Connect Sync
Local Serveur Azure MFA

Important

À compter du 30 septembre 2024, les déploiements de serveurs Azure Multi-Factor Authentication ne serviront plus les requêtes MFA. Pour garantir des services d’authentification ininterrompus et rester dans un état pris en charge, les organisations doivent migrer les données d’authentification de leurs utilisateurs vers l’authentification azure MFA basée sur le cloud.

Options de configuration de l’appareil

Windows Hello Entreprise fournit un ensemble complet de paramètres de stratégie granulaires. Il existe deux options principales pour configurer Windows Hello Entreprise : le fournisseur de services de configuration (CSP) et la stratégie de groupe (GPO).

  • L’option CSP est idéale pour les appareils gérés par le biais d’une solution de gestion des appareils mobiles (GPM), comme Microsoft Intune. Les fournisseurs de services de configuration peuvent également être configurés avec des packages d’approvisionnement
  • L’objet de stratégie de groupe peut être utilisé pour configurer des appareils joints à un domaine et où les appareils ne sont pas gérés via GPM
Modèle de déploiement Options de configuration de l’appareil
🔲 Cloud uniquement CSP
🔲 Cloud uniquement Objet de stratégie de groupe (local)
🔲 Hybride CSP
🔲 Hybride Objet de stratégie de groupe (Active Directory ou local)
🔲 Local CSP
🔲 Local Objet de stratégie de groupe (Active Directory ou local)

Exigences relatives aux licences pour les services cloud

Voici quelques considérations relatives aux exigences de licence pour les services cloud :

  • Windows Hello Entreprise ne nécessite pas d’abonnement Microsoft Entra ID P1 ou P2. Toutefois, certaines dépendances, telles que l’inscription automatique MDM et l’accès conditionnel ,
    • Les appareils gérés via GPM ne nécessitent pas d’abonnement Microsoft Entra ID P1 ou P2. En supprimant l’abonnement, les utilisateurs doivent inscrire manuellement des appareils dans la solution GPM, telle que Microsoft Intune ou une solution GPM non-Microsoft prise en charge
  • Vous pouvez déployer Windows Hello Entreprise à l’aide du niveau Gratuit de l’ID Microsoft Entra. Tous les comptes Gratuits d’ID Microsoft Entra peuvent utiliser l’authentification multifacteur Microsoft Entra pour les fonctionnalités sans mot de passe Windows
  • L’inscription d’un certificat à l’aide de l’autorité d’inscription AD FS nécessite que les appareils s’authentifient auprès du serveur AD FS, ce qui nécessite l’écriture différée de l’appareil, une fonctionnalité d’ID Microsoft Entra P1 ou P2
Modèle de déploiement Type d’approbation Licences de services cloud (minimum)
🔲 Cloud uniquement Non applicable non obligatoire
🔲 Hybride Cloud Kerberos non obligatoire
🔲 Hybride Clé non obligatoire
🔲 Hybride Certificat Microsoft Entra ID P1
🔲 Local Clé Azure MFA, s’il est utilisé comme solution MFA
🔲 Local Certificat Azure MFA, s’il est utilisé comme solution MFA

Important

À compter du 30 septembre 2024, les déploiements de serveurs Azure Multi-Factor Authentication ne serviront plus les requêtes MFA. Pour garantir des services d’authentification ininterrompus et rester dans un état pris en charge, les organisations doivent migrer les données d’authentification de leurs utilisateurs vers l’authentification azure MFA basée sur le cloud.

Configuration requise pour le système d’exploitation

Configuration requise pour Windows

Toutes les versions de Windows prises en charge peuvent être utilisées avec Windows Hello Entreprise. Toutefois, l’approbation Kerberos cloud nécessite des versions minimales :

Modèle de déploiement Type d’approbation Version de Windows
🔲 Cloud uniquement Non applicable Toutes les versions prises en charge
🔲 Hybride Cloud Kerberos - Windows 10 21H2, avec KB5010415 et versions ultérieures
- Windows 11 21H2, avec KB5010414 et versions ultérieures
🔲 Hybride Clé Toutes les versions prises en charge
🔲 Hybride Certificat Toutes les versions prises en charge
🔲 Local Clé Toutes les versions prises en charge
🔲 Local Certificat Toutes les versions prises en charge

Configuration requise pour Windows Server

Toutes les versions de Windows Server prises en charge peuvent être utilisées avec Windows Hello Entreprise en tant que contrôleur de domaine. Toutefois, l’approbation Kerberos cloud nécessite des versions minimales :

Modèle de déploiement Type d’approbation Version du système d’exploitation du contrôleur de domaine
🔲 Cloud uniquement Non applicable Toutes les versions prises en charge
🔲 Hybride Cloud Kerberos - Windows Server 2016, avec KB3534307 et versions ultérieures
- Windows Server 2019, avec KB4534321 et versions ultérieures
- Windows Server 2022
🔲 Hybride Clé Toutes les versions prises en charge
🔲 Hybride Certificat Toutes les versions prises en charge
🔲 Local Clé Toutes les versions prises en charge
🔲 Local Certificat Toutes les versions prises en charge

Préparer les utilisateurs

Lorsque vous êtes prêt à activer Windows Hello Entreprise dans votre organisation, veillez à préparer les utilisateurs en expliquant comment provisionner et utiliser Windows Hello.

Pour en savoir plus, consultez Préparer les utilisateurs.

Étapes suivantes

Maintenant que vous avez lu les différentes options et exigences de déploiement, vous pouvez choisir l’implémentation qui convient le mieux à votre organisation.

Pour en savoir plus sur le processus de déploiement, choisissez un modèle de déploiement et un type d’approbation dans les listes déroulantes suivantes :