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 Microsoft Entra ID, 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 déployer 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’un organization.
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 Windows Hello Entreprise.
Il existe sept domaines main à prendre en compte lors de la planification d’un déploiement Windows Hello Entreprise :
- Options de déploiement
- Configuration requise pour l’infrastructure à clé publique (PKI)
- Exigences relatives à l’authentification auprès de Microsoft Entra ID
- Options de configuration de l’appareil
- Exigences relatives aux licences pour les services cloud
- Configuration requise pour le système d’exploitation
- Préparer les utilisateurs
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 Microsoft Entra ID. Ces organisations utilisent des applications inscrites dans Microsoft Entra ID 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 Microsoft Entra ID. 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 Windows Hello Entreprise clients s’authentifient auprès d’Active Directory. Le type d’approbation n’affecte pas l’authentification à Microsoft Entra ID. Pour cette raison, le type d’approbation n’est pas applicable à un modèle de déploiement cloud uniquement.
Windows Hello Entreprise l’authentification à Microsoft Entra ID utilise toujours la clé, et non un certificat (à l’exception de l’authentification smart carte 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 aux utilisateurs et aux 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 à Microsoft Entra ID, à 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 du 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 Windows Hello Entreprise confiance Kerberos cloud 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 Microsoft Entra ID et Active Directory pour que les utilisateurs puissent accéder aux ressources locales. Il n’y a pas de délai entre l’approvisionnement 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
Windows Hello Entreprise’approbation Kerberos cloud 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 Microsoft Entra ID
Les utilisateurs peuvent s’authentifier auprès de Microsoft Entra ID à 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 Microsoft Entra ID | 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 Microsoft Entra ID à l’aide d’AD FS |
Pour en savoir plus :
- Fédération avec Microsoft Entra ID
- Synchronisation de hachage de mot de passe (PHS)
- Authentification directe (PTA)
Informations techniques de référence sur l’inscription de l’appareil
Pour les déploiements locaux, le serveur exécutant le rôle Services ADFS (AD FS) est responsable de l’inscription de l’appareil. Pour les déploiements cloud uniquement et hybrides, les appareils doivent s’inscrire dans Microsoft Entra ID.
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 Microsoft Entra’aide jointe hybride, 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 | MFA non-Microsoft, via une méthode d’authentification externe dans Microsoft Entra ID ou fédération |
🔲 | Hybride | Microsoft Entra MFA |
🔲 | Hybride | MFA non-Microsoft, via une méthode d’authentification externe dans Microsoft Entra ID ou fédération |
🔲 | Local | Adaptateur AD FS MFA |
Pour plus d'informations :
- Configurer Microsoft Entra paramètres d’authentification multifacteur
- Gérer une méthode d’authentification externe dans Microsoft Entra ID
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 Microsoft Entra ID 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 case activée 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 Windows Hello Entreprise intégrée 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 Microsoft Entra ID. Pendant le processus d’approvisionnement de Window Hello for Business, les utilisateurs inscrivent la partie publique de leurs informations d’identification Windows Hello Entreprise avec Microsoft Entra ID. Microsoft Entra Connect Sync synchronise la clé publique Windows Hello Entreprise avec Active Directory. Cette synchronisation permet à l’authentification unique de Microsoft Entra ID 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 Microsoft Entra ID 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 main pour configurer Windows Hello Entreprise : fournisseur de services de configuration (CSP) et stratégie de groupe (GPO).
- L’option CSP est idéale pour les appareils gérés via une solution mobile Gestion des appareils (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 MDM, par exemple Microsoft Intune ou un GPM non-Microsoft pris en charge
- Vous pouvez déployer Windows Hello Entreprise à l’aide du niveau Microsoft Entra ID Gratuit. Tous les comptes gratuits Microsoft Entra ID peuvent utiliser Microsoft Entra authentification multifacteur pour les fonctionnalités sans mot de passe Windows
- Certaines fonctionnalités d’authentification multifacteur Microsoft Entra nécessitent une licence. Pour plus d’informations, consultez Fonctionnalités et licences pour l’authentification multifacteur Microsoft Entra.
- 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é Microsoft Entra ID 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
Windows Hello Entreprise peut être utilisé pour s’authentifier auprès de toutes les versions de Windows Server prises en charge 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 - Windows Server 2025 |
🔲 | 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 |
Les niveaux fonctionnels de domaine et de forêt minimum requis sont Windows Server 2008 R2 pour tous les modèles de déploiement.
Préparer les utilisateurs
Lorsque vous êtes prêt à activer Windows Hello Entreprise dans votre organization, veillez à préparer les utilisateurs en expliquant comment approvisionner 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 organization.
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 :