Résoudre les problèmes d'ADFS dans Active Directory de Azure et Office 365

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: 3079872
Cet article traite des flux de travail de dépannage pour les problèmes d'authentification pour les utilisateurs fédérés dans Azure Active Directory ou d'Office 365.
Symptômes
  • Les utilisateurs fédérés ne peut pas connecter à Office 365 ou Microsoft Azure même si les utilisateurs gérés uniquement nuage qui ont un suffixe de nom UPN de domainxx.onmicrosoft.com peuvent vous connecter sans problème.
  • La redirection vers Active Directory Federation Services (ADFS) ou SharePoint Team Services ne se produit pas pour un utilisateur fédéré. Ou bien, une erreur « Impossible d'afficher la Page » est déclenchée.
  • Vous recevez un avertissement sur un navigateur liées au certificat lorsque vous essayez de vous authentifier avec AD FS. Cette demande indique que la validation du certificat échoue ou que le certificat n'est pas approuvé.
  • « Méthode d'authentification inconnu » ou les erreurs indiquant que AuthnContext n'est pas pris en charge. Également, les erreurs au niveau du Federation Services ou SharePoint Team Services lorsque vous êtes redirigé à partir d'Office 365.
  • AD FS lève une erreur « Accès refusé ».
  • AD FS lève une erreur indiquant qu'il existe un problème d'accès au site ; Cela inclut un numéro de référence.
  • L'utilisateur est invité à plusieurs reprises des informations d'identification au niveau AD FS.
  • Les utilisateurs fédérés ne peuvent pas s'authentifier à partir d'un réseau externe ou lorsqu'ils utilisent une application qui prend l'itinéraire réseau externe (Outlook, par exemple).
  • Les utilisateurs fédérés ne peut pas se connecter après la modification d'un certificat de signature de jetons sur AD FS.
  • Une erreur « Désolé, mais nous parvenons vous connecter » est déclenchée lorsqu'un utilisateur fédéré se connecte à Office 365 dans Microsoft Azure. Cette erreur comprend les codes d'erreur, tels que C de 8004786, 80041034, 80041317, 80043431, 80048163, 80045C, 06, 8004789A ou mauvaise demande.

Résolution des problèmes de flux de travail
  1. Accès https://login.microsoftonline.com, puis entrez (de nom de connexion de l'utilisateur fédéréune personne@exemple.com). Une fois que vous appuyez sur Tab pour supprimer le focus de la zone de connexion, vérifiez si l'état de la page change pour « Redirection » et que vous êtes redirigé vers votre Active Directory Federation Service (Active Directory Federation Services) pour la connexion.

    En cas de redirection, vous consultez la page suivante :

    La capture d'écran pour l'étape 1
    1. Si aucune redirection se produit et vous êtes invité à entrer un mot de passe sur la même page, cela signifie que Azure Active Directory (AD) ou Office 365 ne reconnaît pas de l'utilisateur ou le domaine de l'utilisateur pour être fédéré. Pour vérifier s'il existe une approbation de fédération entre AD Azure ou d'Office 365 et votre serveur ADFS, exécuter le Get-msoldomain applet de commande PowerShell de publicité Azure. Si un domaine est fédéré, sa propriété d'authentification s'affiche en tant que « Fédérée », comme dans la capture d'écran suivante :

      L'étape sur les domaine fédéré
    2. Si la redirection se produit, mais vous n'êtes pas redirigé vers votre serveur AD FS pour la connexion, vérifiez si le nom du service AD FS résout à la bonne adresse IP et si elle peut se connecter à cette IP sur le port TCP 443.

      Si le domaine est affiché sous la forme « Fédérée », obtenir des informations sur l'approbation de fédération en exécutant les commandes suivantes :
      Get-MsolFederationProperty -DomainName <domain>
      Get-MsolDomainFederationSettings -DomainName <domain>
      Vérifiez l'URI, les URL et les certificats du partenaire de fédération qui est configuré par Office 365 ou AD Azure.
  2. Une fois que vous êtes redirigé vers AD FS, le navigateur peut lève une erreur de niveau de confiance certificat, et pour certains clients et les périphériques qu'il peut vous laisse pas établir une session SSL avec AD FS. Pour résoudre ce problème, procédez comme suit :
    1. Assurez-vous que le certificat du service communications AD FS est présenté au client est la même que celle qui est configurée sur AD FS.

      La capture d'écran à propos de l'étape A

      Dans l'idéal, le certificat de communication du service AD FS doit être le même que le certificat SSL qui est présenté au client lorsqu'il tente d'établir un tunnel SSL avec les services AD FS.

      Dans AD FS 2.0 :

      • Lier le certificat à IIS-> premier site par défaut.
      • Utilisez le composant logiciel enfichable ADFS pour ajouter le même certificat que le certificat de communication du service.

      Dans AD FS 2012 R2 :

      • Utilisez le composant logiciel enfichable AD FS ou Ajouter-adfscertificate commande permettant d'ajouter un certificat de communication du service.
      • Utilisez le Ensemble-adfssslcertificate commande pour définir le même certificat pour liaison SSL.

    2. Vérifiez que ce certificat de communication du service AD FS est approuvé par le client.
    3. Si les clients non compatibles – SNI essayez d'établir une session SSL avec AD FS ou WAP R2 de 2 à 12, la tentative peut échouer. Dans ce cas, envisagez l'ajout d'une entrée de secours sur les serveurs ADFS ou WAP pour prendre en charge les clients non-SNI. Pour plus d'informations, consultez le blog suivant :
  3. Vous pouvez rencontrer une erreur « Méthode d'authentification inconnu » ou des erreurs indiquant que la AuthnContext n'est pas pris en charge au niveau du Federation Services ou SharePoint Team Services lorsque vous êtes redirigé à partir d'Office 365. Cela est plus fréquent lorsque Office 365 et AD Azure redirige l'AD FS ou SharePoint Team Services à l'aide d'un paramètre qui applique une méthode d'authentification. Pour appliquer une méthode d'authentification, utilisez une des méthodes suivantes :
    • Pour WS-Federation, utilisez une chaîne de requête WAUTH pour forcer une méthode d'authentification par défaut.
    • Pour SAML2.0, utilisez le code suivant :
      <saml:AuthnContext><saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef></saml:AuthnContext>
    Lorsque la méthode d'authentification appliquée est envoyée avec une valeur incorrecte, ou si cette méthode d'authentification n'est pas pris en charge sur AD FS ou SharePoint Team Services, vous recevez un message d'erreur avant l'authentification.

    Le tableau suivant indique le type d'authentification URI qui sont reconnus par les Federation Services pour WS-Federation authentification passive.
    Méthode d'authentification souhaitéeURI de wauth
    Authentification par nom et mot de passe utilisateururn : oasis : noms : tc : SAML:1.0:am:password
    Authentification du client SSLurn : ietf:rfc:2246
    Authentification intégrée de Windowsurn : federation : authentification : windows

    Prise en charge SAML classes de contexte d'authentification

    Méthode d'authentification Classe du contexte de l'authentification URI
    Nom d'utilisateur et le mot de passeurn : oasis : noms : tc : SAML:2.0:ac:classes:Password
    Transport de protégé par un mot de passeurn : oasis : noms : tc : SAML:2.0:ac:classes:PasswordProtectedTransport
    Client de Layer Security (TLS) de transporturn : oasis : noms : tc : SAML:2.0:ac:classes:TLSClient
    Certificat X.509urn : oasis : noms : tc : SAML:2.0:ac:classes:X 509
    Authentification intégrée de Windowsurn : federation : authentification : windows
    Kerberosurn : oasis : noms : tc : SAML:2.0:ac:classes:Kerberos

    Pour vous assurer que la méthode d'authentification est pris en charge sur AD FS, vérifiez les points suivants.

    AD FS 2.0

    Sous /ADFS/ls/Web.config, assurez-vous que l'entrée pour le type d'authentification est présente.

    <microsoft.identityServer.web></microsoft.identityServer.web>
    <localAuthenticationTypes></localAuthenticationTypes>
    Ajouter nom = "Forms" page="FormsSignIn.aspx" / >
    <add name="Integrated" page="auth/integrated/"></add>
    <add name="TlsClient" page="auth/sslclient/"></add>
    <add name="Basic" page="auth/basic/"></add>


    AD FS 2.0 : Comment modifier le type d'authentification local

    AD FS 2012 R2

    Sous Gestion d'Active Directory Federation Services, cliquez sur Stratégies d'authentification dans le composant logiciel enfichable AD FS.

    Dans le Authentification principale Cliquez sur Modifier à côté de Paramètres globaux. Vous pouvez également avec le bouton droit Stratégies d'authentification puis sélectionnez Modifier l'authentification principale Global. Ou, dans le Actions volet, sélectionnez Modifier l'authentification principale Global.

    Dans le Modifier la stratégie d'authentification globale fenêtre, sur le Principal onglet, vous pouvez configurer des paramètres dans le cadre de la stratégie d'authentification globale. Par exemple, pour l'authentification principale, vous pouvez sélectionner les méthodes d'authentification disponibles sous Extranet et Intranet.

    ** Vérifiez que que la case à cocher de méthode d'authentification requise est sélectionnée.
  4. Si vous obtenez votre ADFS et que vous entrez des informations d'identification, mais vous ne pouvez pas être authentifié, vérifiez les points suivants.
    1. Problème de réplication Active Directory

      Si la réplication Active Directory est interrompue, les modifications apportées à l'utilisateur ou le groupe peuvent être non synchronisées entre les contrôleurs de domaine. Entre les contrôleurs de domaine, il peut y avoir un mot de passe, UPN, GroupMembership, ou ProxyAddress incompatibilité qui affecte la réponse AD FS (authentification et créances). Vous devez commencer en examinant les contrôleurs de domaine sur le même site que AD FS. Exécution d'un repadmin /showreps ou un DCdiag /v commande doit faire apparaître il y s'a un problème sur les contrôleurs de domaine AD FS est probablement contacter.

      Vous pouvez également collecter un résumé de la réplication Active Directory pour vous assurer que les modifications d'Active Directory sont répliquées correctement sur tous les contrôleurs de domaine. Le repadmin /showrepl * /csv > showrepl.csv sortie est utile pour la vérification de l'état de la réplication. Pour plus d'informations, reportez-vous à la section. Résolution des problèmes de réplication Active Directory.
    2. Compte verrouillé ou désactivé dans Active Directory

      Lorsque l'utilisateur final est authentifié via ADFS, il ou elle ne reçoit pas un message erreur d'indiquant que le compte est verrouillé ou désactivé. À partir d'AD FS et l'audit d'ouverture de session, vous devez être en mesure de déterminer si l'authentification a échoué en raison d'un mot de passe, si le compte est désactivé ou verrouillé et ainsi de suite.

      Pour activer l'audit sur l'AD FS, les serveurs de connexion et d'AD FS, procédez comme suit :
      1. Stratégie locale ou de domaine permet d'activer des succès et des échecs pour les stratégies suivantes :
        • Auditer les événements d'ouverture de session, situé dans l'ordinateur configuration\Windows Settings\Security setting\Local stratégie de Policy\Audit"
        • Auditer l'accès aux objets, situé dans l'ordinateur configuration\Windows Settings\Security setting\Local stratégie de Policy\Audit"
        La capture d'écran sur les stratégies
      2. Désactiver la stratégie suivante :

        D'audit : Paramètres de sous-catégorie de stratégie Force d'audit (Windows Vista ou version ultérieure) pour substituer les paramètres de catégorie de stratégie d'audit

        Cette stratégie se trouve dans ordinateur configuration\Windows Settings\Security setting\Local Option de sécurité\l.

        La capture sur la stratégie d'écran

        Si vous souhaitez effectuer cette configuration à l'aide de l'audit avancé, cliquez sur ici.
      3. Configurez AD FS pour l'audit :
        1. Ouvrir l'AD FS 2.0 Management-composant logiciel enfichable.
        2. Dans le volet Actions , cliquez sur Modifier les propriétés du Service de fédération.
        3. Dans la Propriétés du Service de fédération boîte de dialogue, cliquez sur le événements onglet.
        4. Sélectionnez le des audits de réussite et audits des échecs cases à cocher.

          Le sceenshot sur Activer l'audit de AD FS
        5. Exécuter GPupdate /force sur le serveur.
    3. Nom de Principal du service (SPN) est incorrectement enregistré.

      Il existe peut-être des SPN en double ou un nom principal de service qui est enregistré sous un autre compte que le compte de service AD FS. Pour une configuration de batterie de serveurs AD FS, assurez-vous que SPN hôte et d'Active Directory FSservicename est ajouté sous le compte de service qui exécute le service AD FS. Pour une installation autonome d'AD FS, dans lequel le service s'exécute sous Service de réseau, le SPN doit être sous le compte d'ordinateur du serveur qui héberge AD FS.

      La capture d'écran pour le nom du service AD FS

      Assurez-vous qu'il n'existe pas de SPN en double pour le service AD FS, comme cela peut entraîner des échecs d'authentification avec AD FS. Pour répertorier les noms principaux de service, exécutez SETSPN – L<ServiceAccount></ServiceAccount>.

      La capture d'écran sur la liste de SPN

      Exécuter SETSPN – un hôte et d'Active Directory FSservicename ServiceAccount Pour ajouter le nom principal de service.

      Exécuter SETSPN – X -F Pour vérifier des SPN en double.
    4. UPN en double dans Active Directory

      Un utilisateur peut être en mesure de s'authentifier via AD FS lorsqu'ils utilisent SAMAccountName mais pas pour l'authentification lors de l'utilisation de nom UPN. Dans ce scénario, Active Directory peut contenir deux utilisateurs qui ont le même UPN. Il est possible de se retrouver avec deux utilisateurs qui ont le même UPN, lorsque les utilisateurs sont ajoutés ou modifiés par l'intermédiaire de scripts (ADSIedit, par exemple).

      Lors de l'UPN est utilisé pour l'authentification dans ce scénario, l'utilisateur est authentifié par l'utilisateur en double. Par conséquent, les informations d'identification fournies ne sont pas validées.

      Vous pouvez utiliser des requêtes comme suit pour vérifier s'il existe plusieurs objets qui ont les mêmes valeurs pour un attribut dans Active Directory :
      Dsquery * forestroot -filter UserPrincipalName=problemuser_UPN

      Assurez-vous que le nom UPN de l'utilisateur en double est renommé, afin que la demande d'authentification avec l'UPN est validée par rapport aux objets appropriés.
    5. Dans un scénario, où vous utilisez votre adresse de courriel comme l'ID de connexion dans Office 365, et que vous entrez la même adresse de messagerie lorsque vous êtes redirigé ADFS pour l'authentification, l'authentification peut échouer avec une erreur « NO_SUCH_USER » dans les journaux d'Audit. Pour permettre à ADFS rechercher un utilisateur pour l'authentification à l'aide d'un attribut différent de nom UPN ou SAMaccountname, vous devez configurer AD FS pour prendre en charge d'un ID d'ouverture de session secondaire. Pour plus d'informations, reportez-vous à la section. Configuration des ID de connexion de remplacement.

      AD FS 2012 R2

      1. Installer Mise à jour 2919355.
      2. Mettre à jour la configuration AD FS en exécutant l'applet de commande PowerShell suivante sur tous les serveurs de fédération dans votre batterie de serveurs (si vous avez une batterie de serveurs de travail, vous devez exécuter cette commande sur le serveur principal de AD FS dans votre batterie de serveurs) :

        « AUTORITÉ d'Active Directory » de TargetIdentifier - Set-AdfsClaimsProviderTrust - AlternateLoginID <attribute>- LookupForests <forest domain=""></forest> </attribute>

        RemarqueAlternateLoginID est le nom LDAP de l'attribut que vous souhaitez utiliser pour la connexion. Et LookupForests est la liste des entrées DNS appartenant à vos utilisateurs de forêts.

        Pour activer la fonctionnalité d'ID de connexion secondaire, vous devez configurer à la fois le AlternateLoginID et LookupForests avec une valeur non null, valide les paramètres.

    6. Le compte de service AD FS ne possède pas d'accès en lecture à sur le jeton AD FS qui est la clé privée du certificat signature. Pour ajouter cette autorisation, procédez comme suit :
      1. Lorsque vous ajoutez un nouveau certificat de signature de jetons, vous recevez l'avertissement suivant: « Assurez-vous que la clé privée pour le certificat choisi est accessible au compte de service pour ce Service de fédération sur chaque serveur de la batterie de serveurs. »
      2. Cliquez sur Démarrer, sur exécuter, type MMC.exe, puis appuyez sur ENTRÉE.
      3. Cliquez sur fichier, puis cliquez sur Ajouter/supprimer un composant logiciel enfichable.
      4. Double-cliquez sur certificats.
      5. Sélectionnez le compte de l'ordinateur en question, puis cliquez sur suivant.
      6. Sélectionnez l'ordinateur Local, puis cliquez sur Terminer.
      7. Développez certificats (ordinateur Local), <b00> </b00>personnagel et puis sélectionnez certificats.
      8. Avec le bouton droit de votre nouveau certificat de signature de jetons, sélectionnez Toutes les tâches, puis sélectionnez Gérer les clés privées.

        Le sceenshot à propos de l'étape 8
      9. Ajouter l'accès en lecture à votre compte de service 2.0 AD FS, puis cliquez sur OK.
      10. Fermez les console MMC Certificats.
    7. L'option de Protection étendue pour l'authentification Windows est activée pour le répertoire virtuel AD FS ou LS. Cela peut entraîner des problèmes avec certains navigateurs. Parfois vous pouvez voir ADFS invite à plusieurs reprises des informations d'identification, et cela peut être liée à la Protection étendue paramètre qui est activé pour l'authentification Windows pour l'application AD FS ou LS dans IIS.

      Le sceenshot à propos de l'étape 8
      Lorsque Protection étendue pour l'authentification est activée, les demandes d'authentification sont liés à ces deux les noms principaux de Service (SPN) du serveur sur lequel le client essaie de se connecter et au canal de Transport Layer Security (TLS) sur lequel l'authentification Windows intégrée est exécutée. La protection étendue améliore les fonctionnalités d'authentification de Windows existantes pour atténuer le relais d'authentification ou les attaques « homme au milieu ». Toutefois, certains navigateurs ne fonctionnent pas avec le Protection étendue paramètre ; au lieu de cela, ils demandent plusieurs fois les informations d'identification et refuser l'accès. Désactivation Protection étendue aide est ce scénario.

      Pour plus d'informations, reportez-vous à la section. AD FS 2.0 : Invité en permanence des informations d'identification lors de l'utilisation du débogueur de web de Fiddler.

      Pour AD FS 2012 R2

      Exécutez l'applet de commande suivante pour désactiver Extendedprotection :

      Set-ADFSProperties-ExtendedProtectionTokenCheck aucune

    8. Règles d'autorisation de délivrance de l'approbation de la partie de confiance (RP) peuvent refuser l'accès aux utilisateurs. Sur l'approbation de la partie de confiance AD FS, vous pouvez configurer les règles d'autorisation de délivrance de contrôle si un utilisateur authentifié doit délivrer un jeton pour une partie de confiance. Les administrateurs peuvent utiliser les revendications qui sont émises pour décider si vous souhaitez refuser l'accès à un utilisateur qui est membre d'un groupe qui est affiché sous la forme d'une demande d'indemnisation.

      Si certains utilisateurs fédérés ne peuvent pas s'authentifier via AD FS, vous souhaiterez peut-être vérifier les règles d'autorisation de délivrance pour Office 365 RP si le Autoriser l'accès à tous les utilisateurs règle est configurée.

      La capture sur les règles d'écran
      Si cette règle n'est pas configuré, consulter les règles d'autorisation personnalisée pour vérifier si la condition dans cette règle prend la valeur « true » pour l'utilisateur concerné. Pour plus d'informations, consultez les ressources suivantes :
      Si lorsque vous accédez à directement le serveur AD FS, mais vous ne peut pas vous authentifier lorsque vous accédez à via un proxy de Federation Services AD FS, vous pouvez authentifier à partir d'un intranet, vérifiez les points suivants :
      • Problème de synchronisation de temps sur le serveur AD FS et proxy de Federation Services

        Assurez-vous que l'heure sur le serveur AD FS et l'heure sur le proxy sont synchronisés. Lorsque l'heure sur le serveur AD FS est décalée de plus de cinq minutes de l'heure sur les contrôleurs de domaine, les échecs d'authentification se produisent. Lorsque l'heure sur le proxy de Federation Services n'est pas synchronisé avec AD FS, l'approbation de proxy est affectée et rompue. Par conséquent, une demande qui passe par le proxy de Federation Services échoue.
      • Vérifiez si le proxy de Federation Services approbation avec le service ADFS fonctionne correctement. Exécutez à nouveau la configuration du serveur proxy si vous pensez que le proxy est rompue.
  5. Une fois votre AD FS émet une annonce de jeton, Azure ou Office 365 lève une erreur. Dans ce cas, vérifiez les points suivants :
    • Les revendications qui sont émises par AD FS en jeton doivent correspondre les attributs respectifs de l'utilisateur dans Active Directory Azure. Le jeton pour Azure AD ou Office 365, les affirmations suivantes sont requises.

      WSFED :
      UPN : La valeur de cet argument doit correspondre à l'UPN des utilisateurs dans Active Directory Azure.
      ImmutableID : La valeur de cet argument doit correspondre à la sourceAnchor ou le ImmutableID de l'utilisateur dans Active Directory Azure.

      Pour obtenir la valeur d'attribut utilisateur dans AD Azure, exécutez la ligne de commande suivante : Get-MsolUser-UserPrincipalName.<UPN></UPN>

      SAML 2.0 :
      IDPEmail : La valeur de cet argument doit correspondre le nom d'utilisateur principal des utilisateurs dans Active Directory Azure.
      NAMEID : La valeur de cet argument doit correspondre à la sourceAnchor ou le ImmutableID de l'utilisateur dans Active Directory Azure.

      Pour plus d'informations, reportez-vous à la section. Un fournisseur d'identité SAML 2.0 permet de mettre en œuvre une ouverture de session unique.

      Exemples :
      Ce problème peut se produire lorsque le nom UPN d'un utilisateur synchronisé est modifié dans Active Directory mais sans mise à jour de l'annuaire en ligne. Dans ce scénario, vous pouvez corriger UPN de l'utilisateur dans Active Directory (en correspondance avec le nom d'ouverture de session de l'utilisateur associé) ou exécutez l'applet de commande suivante pour modifier le nom d'ouverture de session de l'utilisateur dans l'annuaire en ligne :

      Set-MsolUserPrincipalName - UserPrincipalName [ExistingUPN] - NewUserPrincipalName [DomainUPN-AD]

      Il peut également être à l'aide de AADsync de synchronisation ENVOI en tant que nom UPN et EMPID comme SourceAnchor, mais la partie de confiance réclamer des règles au niveau de l'ADFS n'ont pas été mis à jour pour envoyer ENVOI en tant que nom UPN et EMPID comme ImmutableID.
    • Il existe une incompatibilité de certificat de signature de jetons entre AD FS et Office 365.

      Il s'agit d'un des problèmes plus courants. AD FS utilise le certificat de signature de jetons pour signer le jeton qui est envoyé à l'utilisateur ou l'application. L'approbation entre l'ADFS et Office 365 est une approbation fédérée qui est basée sur ce certificat de signature de jetons (par exemple, Office 365 vérifie que le jeton reçu est signé à l'aide d'un certificat de signature de jetons du fournisseur de revendications [le service AD FS] qu'il approuve).

      Si le certificat de signature de jetons sur l'AD FS est modifié en raison de la substitution de certificat automatique ou par l'intervention d'un administrateur (après ou avant l'expiration du certificat), les détails du nouveau certificat doit être mis à jour sur le client Office 365 pour le domaine fédéré.

      Office AD 365 ou Azure va tenter d'atteindre le service AD FS, fourni son accessible depuis le réseau public. Nous essayons d'interroger les métadonnées de fédération ADFS à intervalles réguliers, pour extraire des modifications de configuration sur ADFS, principalement le certificat de signature de jetons. Si ce processus ne fonctionne pas, l'administrateur Global doit afficher une notification sur le portail Office 365, avertissement concernant l'expiration de certificat de signature de jetons et les actions à prendre, pour mettre à jour.

      Vous pouvez utiliser Get-MsolFederationProperty - DomainName<domain></domain> Pour effacer la propriété de fédération AD FS et Office 365. Ici, vous pouvez comparer l'empreinte numérique du TokenSigningCertificate, pour vérifier si la configuration de clients Office 365 pour votre domaine fédéré est synchronisée avec AD FS. Si vous trouvez une incohérence dans la configuration de certificat de signature de jetons, exécutez la commande suivante pour mettre à jour :
      Update-MsolFederatedDomain -DomainName <domain> -SupportMultipleDomain
      Vous pouvez également exécuter l'outil suivant pour planifier une tâche sur le serveur AD FS qui va contrôler pour la restauration automatique-certificat du jeton de signature de certificat et de mise à jour de l'Office 365 client automatiquement.

      Outil d'Installation de Microsoft Office 365 fédération mise à jour des métadonnées Automation

      Vérifier et gérer l'authentification unique avec ADFS
    • Règles de demande de transformation d'émission pour Office 365 RP ne sont pas configurés correctement.

      Dans un scénario où vous avez plusieurs domaines de premier niveau (domaines de niveau supérieur), vous pouvez avoir des problèmes d'ouverture de session si la Supportmultipledomain commutateur n'a pas été utilisé lors de l'approbation RP a été créée et mis à jour. Pour plus d'informations, cliquez sur ici.
    • Assurez-vous que le cryptage de jeton est pas utilisé par AD FS ou STS lorsqu'un jeton est émis AD Azure et Office 365.
  6. Il y a des informations d'identification mises en cache obsolètes dans le Gestionnaire d'informations d'identification Windows.

    Parfois lors de la connexion à partir d'une station de travail sur le portail du (ou lors de l'utilisation d'Outlook), lorsque l'utilisateur est invité à entrer vos informations d'identification, les informations d'identification peuvent être enregistrées pour la cible (service Office 365 ou AD FS) dans le Gestionnaire d'informations d'identification Windows (Gestionnaire de Accounts\Credential d'un Panel\User de contrôle). Cela permet d'éviter une invite d'informations d'identification pendant un certain temps, mais il peut provoquer un problème une fois que le mot de passe a été modifié et le Gestionnaire d'informations d'identification n'est pas mis à jour. Dans ce scénario, les informations d'identification obsolètes sont envoyées au service AD FS, et par conséquent, l'authentification échoue. Suppression ou les informations d'identification mises en cache, dans le Gestionnaire d'informations d'identification Windows de mise à jour peut aider.
  7. Assurez-vous que l'algorithme de hachage sécurisé qui est configuré sur la confiance partie de confiance pour Office 365 est défini sur SHA1.

    Lorsque l'approbation entre les Azure AD/Office 365 et de SharePoint Team Services/AD FS utilise le protocole SAML 2.0, l'algorithme de hachage sécurisé configuré pour signature numérique doit être SHA1.
  8. Si aucune des causes ci-dessus s'applique à votre situation, créer un cas de support avec Microsoft et leur demander de vérifier si le compte d'utilisateur apparaît toujours sous le locataire d'Office 365. Pour plus d'informations, consultez les ressources suivantes :

    Message d'erreur à partir d'AD FS 2.0, lorsqu'un utilisateur fédéré se connecte à Office 365: « Problème lors de l'accès au site »

    Un utilisateur fédéré est constamment invité pour les informations d'identification lorsqu'il se connecte au point de terminaison AD FS 2.0 service lors de la connexion à Office 365
  9. Selon le service cloud (intégré à AD Azure) vous accédez, la demande d'authentification est envoyée à AD FS peut-être varier. Par exemple : certaines demandes peuvent inclure des paramètres supplémentaires tels que Wauth ou Wfresh, et ces paramètres peuvent entraîner un comportement différent au niveau AD FS.

    Nous vous recommandons que binaires d'ADFS toujours actualisée pour inclure les correctifs pour les problèmes connus. Pour plus d'informations sur les dernières mises à jour, consultez le tableau suivant.

Avertissement : cet article a été traduit automatiquement

Propriétés

ID d'article : 3079872 - Dernière mise à jour : 08/10/2015 07:36:00 - Révision : 2.0

Windows Server 2008 Datacenter, Windows Server 2008 Enterprise, Windows Server 2008 Foundation, Windows Server 2008 Standard, Windows Server 2008 R2 Datacenter, Windows Server 2008 R2 Enterprise, Windows Server 2008 R2 Foundation, Windows Server 2008 R2 Standard, Windows Server 2012 Foundation, Windows Server 2012 Essentials, Windows Server 2012 Datacenter, Windows Server 2012 Standard, Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Essentials, Windows Server 2012 R2 Foundation, Windows Server 2012 R2 Standard

  • kbmt KB3079872 KbMtfr
Commentaires