Comment utiliser les journaux de trace Fiddler pour AMF dans Office 365 et Azure AD

IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d’une traduction incorrecte du contenu ou de son utilisation par les clients.

La version anglaise de cet article est la suivante: 3106807
Plus d'informations
Si un compte d'utilisateur est fédéré, l'utilisateur est redirigé vers le Service serveur de jeton pour l'authentification et à login.microsoftonline.com, et le jeton SAML est émis par le STS. Si l'utilisateur est géré, login.microsoftonline.com authentifie l'utilisateur par mot de passe de l'utilisateur.

AMF démarre après le mot de passe de l'utilisateur ont été vérifiée par AD Azure ou SharePoint Team Services. La SANeeded = 1 cookie sera définie si l'utilisateur est activé pour l'authentification dans le répertoire Office 365 ou Azure AMF. La communication entre le client et l'après que l'authentification de mot de passe utilisateur semblable au suivant de login.microsoftonline.com :
POST https://login.microsoftonline.com/login.srf HTTP/1.1Host: login.microsoftonline.comHTTP/1.1 302 FoundSet-Cookie: SANeeded=1; domain=login.microsoftonline.com;secure= ;path=/;HTTPOnly= ;version=1

Scénario 1: Utilisation scénario de l'AMF

La SANeeded = 1 cookie est défini une fois l'authentification de mot de passe. Le trafic réseau est alors redirigé vers le point de terminaison : https://login.microsoftonline.com/StrongAuthCheck.srf?, et les méthodes d'authentification disponibles sont demandées.




AMF commence par BeginAuth, et l'appel téléphonique est déclenchée sur le back-end pour le fournisseur de service téléphonique.




Après que autorisation de l'AMF a commencé, le client commence à interroger des toutes les 10 secondes du même point de terminaison pour la méthode EndAuth pour vérifier si l'authentification est terminée. Jusqu'à ce que l'appel a été prélevé et vérifié, le Resultvalue est retourné en tant que AuthenticationPending.




Lorsque le téléphone a été prélevé et vérifié, la réponse à la requête suivante pour EndAuth sera un ResultValue de succès. En outre, l'utilisateur a terminé l'authentification Mulitifactor. Également le Set-Cookie : SANeeded = xxxxxxx cookie est défini dans la réponse, qui est accordée au point de terminaison : login.srf l'authentification complète.


Scénario 2: Lorsque le téléphone est hors de couverture ou de téléphone n'est pas prélevée

Lorsque le téléphone n'est pas prélevé et vérifié dans les 60 secondes après que l'appel est effectué, la ResultValue sera définie comme UserVoiceAuthFailedPhoneUnreachable. Et à la requête suivante pour la méthode EndAuth , UserVoiceAuthFailedPhoneUnreachable est retourné, comme dans Fiddler.


Scénario 3: L'alerte de fraude déclenchement de bloquer le compte dans le cloud

Lorsque le téléphone n'a pas été prélevé et une alerte de fraude validée dans les 60 secondes après que l'appel est effectué, le ResultValue est défini en tant que AuthenticationMethodFailed. Et à la requête suivante pour la méthode EndAuth , une réponse AuthenticationMethodFailed est retournée, comme dans Fiddler.



Scénario 4: pour un compte bloqué

Si l'utilisateur est bloqué, ResultValue sera définie comme UserIsBlocked. À la première requête pour la méthode EndAuth , UserIsBlocked sera retourné, comme dans Fiddler.




Solution : En cas d'Azure AMF avec un abonnement Azure, vous pouvez débloquer par une première connexion à manage.windowsazure.com. Puis, sélectionnez Directory > utilisateurs et gérer de multiples facteurs d'authentification> Service paramètres. À la fin de la page, sélectionnez Atteindre le portail. Maintenant, dans https://pfweb.phonefactor.NET/framefactory, sélectionnez Les utilisateurs de bloquer/débloquer pour trouver la liste des utilisateurs bloqués.

Si AMF est activée via Office 365, ouvrez un incident de support avec Microsoft pour débloquer.

Scénario 5: AMF comptes gérés

Dans ce cas, l'authentification reste la même, mais les points de terminaison sera https://login.microsoftonline.com/Common/SAS/BeginAuth et https://login.microsoftonline.com/Common/SAS/EndAuth au lieu de https://login.microsoftonline.com/StrongAuthCheck.srf? comme pour les comptes fédérés.

Avertissement : Cet article a été traduit automatiquement.

Propriétés

ID d'article : 3106807 - Dernière mise à jour : 11/09/2015 18:59:00 - Révision : 1.0

Microsoft Office 365, Microsoft Azure Active Directory

  • kbhowto kbinfo kbexpertiseadvanced kbsurveynew kbmt KB3106807 KbMtfr
Commentaires