Questions fréquemment posées sur l’authentification multifacteur Microsoft Entra

Avec le serveur d’authentification multifacteur, les données utilisateur sont stockées uniquement sur les serveurs locaux. Aucune donnée utilisateur persistante n'est stockée dans le cloud. Lorsque l’utilisateur effectue une vérification en deux étapes, le serveur d’authentification multifacteur envoie des données au service cloud d’authentification multifacteur Microsoft Entra pour l’authentification. La communication entre le serveur d’authentification multifacteur et le service cloud d’authentification multifacteur utilise ssl (Secure Sockets Layer) ou TLS (Transport Layer Security) sur le port 443 sortant.

Lorsque les demandes d’authentification sont envoyées au service cloud, les données collectées pour les rapports d’utilisation et d’authentification. Les champs de données suivants sont inclus dans les journaux d’activité de vérification en deux étapes :

• ID unique (nom d’utilisateur ou ID de serveur multifacteur local)
• Prénom et nom (facultatif)
• Adresse de messagerie (facultatif)
• Numéro de téléphone (en cas d’utilisation de l’authentification par appel vocal ou SMS)
• Jeton de l’appareil (en cas d’utilisation de l’authentification par application mobile)
• Mode d'authentification
• Résultat de l'authentification
• nom du serveur d’authentification multifacteur
• IP du serveur d’authentification multifacteur
• Adresse IP du client (si disponible)

Les champs facultatifs peuvent être configurés dans le serveur d’authentification multifacteur.

Le résultat de la vérification (réussite ou échec) et le motif de refus sont stockés avec les données d’authentification. Celles-ci sont disponibles dans les rapports d’utilisation et d’authentification.

Pour plus d’informations, consultez Résidence des données et données client pour l’authentification multifacteur Microsoft Entra.

Aux États-Unis, nous utilisons les codes courts suivants :

• 97671
• 69829
• 51789
• 99399

Au Canada, nous utilisons les codes courts suivants :

• 759731
• 673801

Il n'est pas garanti que les notifications d’authentification multifacteur envoyées par SMS ou message vocal proviennent systématiquement du même numéro. Dans l’intérêt de nos utilisateurs, nous pouvons à tout moment ajouter ou supprimer des codes courts pour refléter les ajustements apportés aux routes et améliorer la remise des SMS.

Nous ne prenons pas en charge les codes courts pour les pays/régions en dehors des États-Unis et du Canada.

Oui, dans certains cas, qui impliquent généralement des demandes d’authentification répétées dans une courte fenêtre de temps, l’authentification multifacteur Microsoft Entra limite les tentatives de connexion des utilisateurs pour protéger les réseaux de télécommunications, atténuer les attaques de type fatigue MFA et protéger ses propres systèmes pour l’avantage de tous les clients.

Bien que nous ne partageons pas de limites de limitation spécifiques, elles sont basées sur une utilisation raisonnable.

Non, vous n'êtes pas facturé pour les appels téléphoniques individuels passés ou les messages texte envoyés aux utilisateurs via l'authentification multifacteur Microsoft Entra. Si vous utilisez un fournisseur MFA par authentification, vous êtes facturé pour chaque authentification, mais pas pour la méthode utilisée.

Les utilisateurs peuvent se voir facturer les appels téléphoniques ou les SMS qu’ils reçoivent, en fonction de leur service téléphonique personnel.

La facturation est basée sur le nombre d'utilisateurs configurés pour utiliser l'authentification multifacteur, qu'ils aient ou non effectué une vérification en deux étapes ce mois-là.

Lorsque vous créez un fournisseur MFA par utilisateur ou par authentification, l’abonnement Azure de votre organisation est facturé chaque mois en fonction de l’utilisation. Ce modèle de facturation est similaire à celui d’Azure pour l’utilisation de machines virtuelles et de Web Apps.

Quand vous souscrivez un abonnement à l’authentification multifacteur Microsoft Entra, votre organisation paie seulement les frais de licence annuels de chaque utilisateur. Les licences MFA et les offres Microsoft 365, Microsoft Entra ID P1 ou P2 ou Enterprise Mobility + Security sont facturées de cette manière.

Pour plus d’informations, consultez l’article Comment obtenir l’authentification multifacteur Microsoft Entra.

Les paramètres de sécurité par défaut peuvent être activés dans le niveau Microsoft Entra ID Free. Avec les paramètres de sécurité par défaut, tous les utilisateurs sont activés pour l'authentification multifacteur à l'aide de l'application Microsoft Authenticator. Il n’est pas possible d’utiliser la vérification par SMS ou appel téléphonique avec les paramètres de sécurité par défaut, mais uniquement l’application Microsoft Authenticator.

Pour plus d’informations, consultez Présentation des paramètres de sécurité par défaut.

Si votre organisation acquiert MFA en tant que service autonome avec une facturation à la consommation, vous choisissez un modèle de facturation lorsque vous créez un fournisseur MFA. Vous ne pouvez pas modifier le modèle de facturation après la création d’un fournisseur MFA.

Si votre fournisseur d’authentification multifacteur n’est pas lié à un locataire Microsoft Entra ou si vous liez le nouveau fournisseur d’authentification multifacteur à un autre locataire Microsoft Entra, les paramètres utilisateur et les options de configuration ne sont pas transférés. Par ailleurs, les serveurs MFA existants doivent être réactivés à l’aide des informations d’identification d’activation générées via le nouveau fournisseur MFA. La réactivation des serveurs MFA pour les lier au nouveau fournisseur MFA n’a pas d’impact sur l’authentification par appel téléphonique et sms, mais les notifications d’application mobile arrêtent de fonctionner pour tous les utilisateurs jusqu’à ce qu’ils réactivent l’application mobile.

Pour plus d’informations sur les fournisseurs MFA, consultez Démarrage avec un fournisseur d’authentification multifacteur Azure.

Dans certains cas, oui.

Si votre annuaire a un fournisseur d’authentification multifacteur Microsoft Entra par utilisateur, vous pouvez ajouter des licences MFA. Les utilisateurs disposant de licences ne sont pas comptabilisés dans la facturation basée sur la consommation par utilisateur. Les utilisateurs sans licence peuvent toujours être activés pour MFA via le fournisseur MFA. Si vous achetez et attribuez des licences pour tous vos utilisateurs configurés pour utiliser l'authentification multifacteur, vous pouvez supprimer le fournisseur d'authentification multifacteur Microsoft Entra. Vous pouvez toujours créer un autre fournisseur MFA par utilisateur si vous prévoyez d’avoir plus d’utilisateurs que de licences à l’avenir.

Si votre annuaire a un fournisseur d’authentification multifacteur Microsoft Entra par authentification, vous êtes toujours facturé pour chaque authentification dès lors que le fournisseur MFA est lié à votre abonnement. Vous pouvez attribuer des licences MFA aux utilisateurs, mais vous continuez d’être facturé pour chaque demande de vérification en deux étapes, qu’elle provienne d’une personne à laquelle une licence MFA a été affectée ou non.

Si votre organisation utilise un modèle de facturation basé sur la consommation, Microsoft Entra ID est facultatif, mais pas obligatoire. Si votre fournisseur MFA n’est pas lié à un locataire Microsoft Entra, vous pouvez uniquement déployer azure Multifactor Authentication Server localement.

Microsoft Entra ID est requis pour le modèle de licence, car les licences sont ajoutées au locataire Microsoft Entra quand vous les achetez et que vous les affectez à des utilisateurs de l’annuaire.

Demandez à vos utilisateurs d’essayer jusqu’à cinq fois en 5 minutes d’obtenir un appel téléphonique ou un SMS pour l’authentification. Microsoft utilise plusieurs fournisseurs pour distribuer les appels et les SMS. Si cette approche ne fonctionne pas, ouvrez un cas de support afin d'y remédier.

Les applications de sécurité tierces peuvent également bloquer le SMS ou l'appel téléphonique du code de vérification. Si vous utilisez une application de sécurité tierce, essayez de désactiver la protection, puis demandez l’envoi d’un autre code de vérification MFA.

Si les étapes précédentes ne fonctionnent pas, vérifiez si les utilisateurs sont configurés pour plusieurs méthodes de vérification. Essayez de vous reconnecter, mais sélectionnez une autre méthode de vérification sur la page de connexion.

Pour plus d’informations, consultez le Guide de dépannage de l'utilisateur final.

Vous pouvez réinitialiser le compte de l’utilisateur en lui demandant d’effectuer à nouveau le processus d’inscription. Apprenez-en davantage sur la gestion des paramètres des utilisateurs et des appareils avec l'authentification multifacteur Microsoft Entra dans le cloud.

Supprimez tous les mots de passe d’applications de l’utilisateur afin d’empêcher tout accès non autorisé. Une fois que l’utilisateur dispose d’un appareil de remplacement, il peut recréer les mots de passe. Apprenez-en davantage sur la gestion des paramètres des utilisateurs et des appareils avec l'authentification multifacteur Microsoft Entra dans le cloud.

Si votre organisation utilise encore des clients hérités et si vous avez autorisé l’utilisation de mots de passe d’application, vos utilisateurs ne peuvent pas se connecter à ces clients hérités avec leur nom d’utilisateur et leur mot de passe. Au lieu de cela, ils doivent configurer des mots de passe d’application. Vos utilisateurs doivent effacer (supprimer) leurs informations de connexion, redémarrer l’application, puis se connecter avec leur nom d’utilisateur et leur mot de passe d’application au lieu de leur mot de passe standard.

Si votre organisation ne comporte pas de clients hérités, vous ne devez pas autoriser vos utilisateurs à créer de mots de passe d’application.

La remise de SMS n’est pas garantie en raison de facteurs incontrôlables susceptibles d’affecter la fiabilité du service. Sont notamment en cause le pays ou la région de destination, l’opérateur de téléphonie mobile et la puissance du signal.

Les applications de sécurité tierces peuvent également bloquer le SMS ou l'appel téléphonique du code de vérification. Si vous utilisez une application de sécurité tierce, essayez de désactiver la protection, puis demandez l’envoi d’un autre code de vérification MFA.

Si vos utilisateurs ont souvent des problèmes liés à la fiabilité de la réception des SMS, indiquez leur d’utiliser plutôt l’application Microsoft Authenticator ou l’appel téléphonique. L’application Microsoft Authenticator peut recevoir des notifications à la fois sur des connexions cellulaires et Wi-Fi. En outre, l’application mobile peut générer des codes de vérification même si l’appareil n’a aucun signal. L’application Microsoft Authenticator est disponible pour Android, iOS et Windows Phone.

Oui, dans certains cas.

Pour les SMS unidirectionnels avec un serveur MFA version 7.0 ou supérieure, vous pouvez configurer le paramètre de délai d’expiration en définissant une clé de Registre. Une fois le SMS envoyé par le service cloud MFA, le code de vérification (ou code secret à usage unique) est retourné au serveur MFA. Le serveur MFA stocke le code en mémoire pendant 300 secondes par défaut. Si l’utilisateur n’entre pas son code avant l’expiration du délai de 300 secondes, son authentification est refusée. Suivez ces étapes pour modifier le paramètre de délai d’expiration par défaut :

1. Atteindre HKLM\Software\Wow6432Node\Positive Networks\PhoneFactor.
2. Créez une clé de Registre DWORD appelée pfsvc_pendingSmsTimeoutSeconds, et définissez la durée de stockage en secondes des codes secrets à usage unique du serveur MFA.

Si les utilisateurs ne répondent pas au SMS avant la fin du délai d’expiration défini, leur authentification est refusée.

Pour les SMS unidirectionnels avec l’authentification multifacteur Microsoft Entra dans le cloud (y compris l’adaptateur AD FS ou l’extension Network Policy Server), vous ne pouvez pas configurer le paramètre de délai d’expiration. Microsoft Entra ID stocke le code de vérification pendant 180 secondes.

Si vous utilisez le serveur d’authentification multifacteur, vous pouvez importer des jetons de mot de passe à usage unique (TOTP) basés sur le temps et basés sur l’authentification unique (OATH) tiers, puis les utiliser pour la vérification en deux étapes.

Vous pouvez utiliser des jetons ActiveIdentity qui sont des jetons OATH TOTP si vous placez la clé secrète dans un fichier CSV et que vous importez sur le serveur d’authentification multifacteur. Vous pouvez utiliser des jetons OATH avec les services de fédération Active Directory (AD FS), l’authentification par formulaires Internet Information Server (IIS) et le protocole RADIUS (Remote Authentication Dial-In User Service) à partir du moment où le système client peut accepter une entrée utilisateur.

Vous pouvez importer des jetons OATH TOTP tiers avec les formats suivants :

• Conteneur portable de clé symétrique (PSKC)
• CSV si le fichier contient un numéro de série, une clé secrète au format Base 32 et un intervalle de temps

Oui, mais si vous utilisez Windows Server 2012 R2 ou une version ultérieure, vous pouvez le faire uniquement avec la Passerelle des services Bureau à distance (passerelle RD).

Les modifications de sécurité dans Windows Server 2012 R2 ont changé la façon dont le serveur d’authentification multifacteur se connecte au package de sécurité LSA (Local Security Authority) dans Windows Server 2012 et versions antérieures. Pour les versions de Terminal Services sous Windows 2012 ou une version antérieure, vous pouvez sécuriser une application avec l’authentification Windows. Si vous utilisez Windows Server 2012 R2, vous devez utiliser une passerelle RD.

Lorsque les appels d’authentification multifacteur sont placés via le réseau téléphonique public, ils sont parfois routés via un opérateur qui ne prend pas en charge l’ID de l’appelant. En raison du comportement de l'opérateur, l'identification de l'appelant n'est pas garantie, même si le système d'authentification multifacteur l'envoie toujours.

Il existe plusieurs raisons à cela :

• L’utilisateur a été activé pour MFA par son administrateur dans Microsoft Entra ID, mais n’a pas encore enregistré d’informations de sécurité pour son compte.
• L'utilisateur a été activé pour la réinitialisation du mot de passe en libre-service dans Microsoft Entra ID. Les informations de sécurité l’aident à réinitialiser son mot de passe ultérieurement en cas d’oubli.
• L’utilisateur a accédé à une application dotée d’une stratégie d’accès conditionnel exigeant la MFA et n’est pas encore enregistré pour celle-ci.
• L’utilisateur enregistre un appareil avec l’ID Microsoft Entra (y compris la jointure Microsoft Entra) et votre organisation nécessite MFA pour l’enregistrement de l’appareil, mais l’utilisateur ne s’est pas encore inscrit à MFA.
• L’utilisateur génère Windows Hello Entreprise dans Windows 10 (qui nécessite MFA) et n’a pas encore été enregistré pour la MFA.
• L’organisation a créé et activé une stratégie d’inscription MFA qui a été appliquée à l’utilisateur.
• L’utilisateur a été précédemment enregistré pour MFA, mais a choisi une méthode de vérification, qui a depuis été désactivée par un administrateur. L’utilisateur doit donc de nouveau passer par l’inscription MFA pour sélectionner une nouvelle méthode de vérification par défaut.

Demandez à l’utilisateur de suivre la procédure ci-dessous pour supprimer son compte de l'application Microsoft Authenticator, puis l'ajouter à nouveau :

1. Accédez à leur profil du compte et connectez-vous avec un compte de l’organisation.
2. Sélectionnez Vérification de sécurité supplémentaire.
3. Supprimez le compte existant de l’application Microsoft Authenticator.
4. Sélectionnez Configurer, puis suivez les instructions pour reconfigurer Microsoft Authenticator.

L’erreur 0x800434D4L se produit lorsque vous essayez de vous connecter à une application non-rowser, installée sur un ordinateur local, qui ne fonctionne pas avec les comptes qui nécessitent une vérification en deux étapes.

Une solution de contournement pour cette erreur consiste à avoir des comptes d’utilisateur distincts pour les opérations d’administration et non administratives. Plus tard, vous pouvez lier des boîtes aux lettres entre votre compte administrateur et un compte non administrateur afin de pouvoir vous connecter à Outlook à l’aide de votre compte non administrateur. Pour plus d’informations sur cette solution, consultez Permettre à un administrateur d’ouvrir et d’afficher le contenu de la boîte aux lettres d’un utilisateur.

Erreur 1073741715 = Échec d’état de l’ouverture de session -> La tentative d’ouverture de session n’est pas valide. Cela est dû à un nom d’utilisateur incorrect ou à une authentification incorrecte.

Raison plausible de cette erreur : Si les informations d’identification principales entrées sont correctes, il peut y avoir une différence au niveau de la version NTLM prise en charge sur le serveur MFA et le contrôleur de domaine. Le serveur MFA prend uniquement en charge NTLMv1 (LmCompatabilityLevel=1 à 4) et non NTLMv2 (LmCompatabilityLevel=5).

Étapes suivantes

Si vous ne trouvez pas la réponse à votre question ici, les options de support suivantes sont disponibles :

• Recherchez des solutions aux problèmes techniques courants dans la base de connaissances du support Microsoft.
• Recherchez et explorez des questions et des réponses techniques de la communauté, ou posez votre question dans les Questions et réponses Microsoft Entra.
• Contactez microsoft professionnel via prise en charge du serveur d’authentification multifacteur. Lorsque vous nous contactez, veillez à inclure autant d’informations que possible concernant votre problème. Vous pouvez notamment préciser la page sur laquelle vous avez rencontré l’erreur, le code d’erreur spécifique, l’ID de session spécifique et l’ID de l’utilisateur qui a vu l’erreur.