L’authentification basée sur les revendications ne valide pas l’utilisateur dans SharePoint Server

 

**Sapplique à :**SharePoint Foundation 2013, SharePoint Server 2013, SharePoint Server 2016

**Dernière rubrique modifiée :**2017-09-20

**Résumé :**Cet article décrit les outils et les techniques utiles pour résoudre les échecs des tentatives d’authentification basée sur les revendications, recommandée par SharePoint Server 2016 et SharePoint 2013 pour permettre aux utilisateurs d’accéder aux applications web.

Quand les utilisateurs tentent de se connecter à une application web, les journaux enregistrent les événements d’échec de l’authentification. Si vous utilisez des outils fournis par Microsoft et que vous adoptez une approche systématique pour examiner les causes des échecs, vous pouvez découvrir les problèmes courants liés à l’authentification basée sur les revendications et les résoudre.

Pour pouvoir accéder à une ressource SharePoint il faut à la fois une authentification et une autorisation. Quand vous utilisez les revendications, l’authentification vérifie que le jeton de sécurité est valide. L’autorisation vérifie que l’accès à la ressource est autorisé, d’après l’ensemble des revendications du jeton de sécurité et les autorisations configurées pour la ressource.

Pour déterminer si l’accès est bloqué par l’authentification ou l’autorisation, examinez soigneusement le message d’erreur de la fenêtre du navigateur.

  • S’il indique que l’utilisateur n’a pas accès au site, l’authentification a été acceptée mais pas l’autorisation. Pour résoudre l’autorisation, essayez les solutions suivantes :

    • La raison la plus courante d’un échec d’autorisation quand vous utilisez l’authentification basée sur les revendications SAML (Security Assertion Markup Language) est que les autorisations ont été assignées au compte Windows de l’utilisateur (domaine\utilisateur) et non à sa revendication d’identité SAML.

    • Vérifiez que l’utilisateur ou le groupe auquel il appartient a été configuré pour utiliser les autorisations appropriées. Pour plus d’informations, voir Autorisations utilisateur et niveaux d’autorisation dans SharePoint Server.

    • Utilisez les outils et techniques décrits dans cet article pour déterminer l’ensemble de revendications du jeton de sécurité de l’utilisateur et le comparer avec les autorisations configurées.

  • Si le message indique que l’authentification a échoué, le problème se situe au niveau de l’authentification. Si la ressource est contenue dans une application web SharePoint qui utilise l’authentification basée sur les revendications, utilisez les informations de cet article pour tenter de résoudre le problème.

Outils de résolution de problèmes

Les outils de résolution de problèmes suivants sont fournis par Microsoft pour recueillir des informations sur l’authentification basée sur les revendications dans SharePoint Server :

  • Utilisez les journaux ULS (Unified Logging System) pour obtenir les détails des transactions d’authentification.

  • Utilisez l’Administration centrale pour vérifier les détails des paramètres de l’authentification utilisateur pour les applications web et les zones SharePoint et configurer les niveaux de journalisation ULS.

  • Si vous utilisez les services ADFS (Active Directory Federation Services) 2.0 en tant que fournisseur de fédération pour l’authentification basée sur les revendications SAML, vous pouvez utiliser la journalisation du service ADFS pour déterminer les revendications contenues dans les jetons de sécurité émis par les services ADFS aux ordinateurs clients web.

  • Utilisez Moniteur réseau 3.4 pour capturer et examiner les détails du trafic réseau de l’authentification utilisateur.

Définition du niveau de journalisation ULS pour l’authentification utilisateur

La procédure suivante configure SharePoint Server pour enregistrer le maximum d’informations sur les tentatives d’authentification basée sur les revendications.

Pour configurer la journalisation du maximum d’informations sur l’authentification utilisateur dans SharePoint Server

  1. Dans l’Administration centrale, cliquez sur Analyse dans la barre de lancement rapide, puis cliquez sur Configurer la journalisation des diagnostics.

  2. Dans la liste des catégories, développez SharePoint Foundation, puis sélectionnez Authentification Autorisation et Authentification basée sur les revendications.

  3. Dans Événement le moins critique à enregistrer dans le journal d’événements, sélectionnez Commentaires.

  4. Dans Événement le moins critique à enregistrer dans le journal de suivi, sélectionnez Commentaires.

  5. Cliquez sur OK.

Pour optimiser les performances en dehors de la résolution des problèmes d’authentification basée sur les revendications, procédez comme suit pour définir la journalisation de l’authentification utilisateur sur ses valeurs par défaut.

Pour configurer la journalisation par défaut des informations sur l’authentification utilisateur dans SharePoint Server

  1. Dans l’Administration centrale, cliquez sur Analyse dans la barre de lancement rapide, puis cliquez sur Configurer la journalisation des diagnostics.

  2. Dans la liste des catégories, développez SharePoint Foundation, puis sélectionnez Authentification Autorisation et Authentification basée sur les revendications.

  3. Dans Événement le moins critique à enregistrer dans le journal d’événements, sélectionnez Informations.

  4. Dans Événement le moins critique à enregistrer dans le journal de suivi, sélectionnez Moyen.

  5. Cliquez sur OK.

Configuration de la journalisation ADFS

Même après l’activation du niveau maximal de journalisation du service ULS, SharePoint Server n’enregistre pas l’ensemble des revendications reçues dans un jeton de sécurité. Si vous utilisez les services AD FS pour l’authentification basée sur les revendications SAML, vous pouvez activer la journalisation AD FS et utiliser l’observateur d’événements pour examiner les revendications des jetons de sécurité émis par SharePoint Server.

Pour activer la journalisation ADFS

  1. Sur le serveur ADFS, dans l’observateur d’événements, cliquez sur Afficher, puis sur Afficher les journaux d’analyse et de débogage.

  2. Dans l’arborescence de la console de l’observateur d’événements, développez Journaux des applications et des services/Suivi des services ADFS 2.0.

  3. Cliquez avec le bouton droit sur Déboguer, puis cliquez sur Activer le journal.

  4. Ouvrez le dossier %ProgramFiles%\Active Directory Federation Services 2.0.

  5. Utilisez le Bloc-notes pour ouvrir le fichier Microsoft.IdentityServer.ServiceHost.Exe.Config.

  6. Cliquez sur Edition, sur Rechercher, tapez <source name=“Microsoft.IdentityModel“ switchValue="Off">, puis cliquez sur OK.

  7. Changez switchValue="Off" en switchValue="Verbose".

  8. Cliquez sur Fichier, sur Enregistrer, puis quittez le Bloc-notes.

  9. Dans le composant logiciel enfichable Services, cliquez avec le bouton droit sur service ADFS 2.0, puis cliquez sur Redémarrer.

Vous pouvez désormais utiliser l’observateur d’événements sur le serveur ADFS pour examiner les détails des revendications dans le nœud Journaux des applications et des services/Suivi des services ADFS 2.0/Débogage. Recherchez des événements dont l’ID d’événement est 1001.

Vous pouvez aussi énumérer les revendications avec un composant HttpModule ou WebPart ou via OperationContext. Pour plus d’informations, voir Comment obtenir toutes les revendications utilisateur au moment de l’augmentation des revendications dans SharePoint 2010. Ces informations concernent SharePoint 2010, mais s’appliquent aussi à SharePoint 2013.

Méthodologie de résolution des problèmes de l’authentification utilisateur basée sur les revendications

Les étapes suivantes peuvent vous aider à déterminer la cause de l’échec des tentatives d’authentification basée sur les revendications.

Étape 1 : Déterminer les causes de l’échec des tentatives d’authentification

Pour obtenir des informations détaillées et définitives sur l’échec d’une tentative d’authentification, vous devez les rechercher dans les journaux ULS de SharePoint. Ces fichiers journaux sont stockés dans le dossier %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\15\LOGS.

Vous pouvez rechercher manuellement la tentative d’authentification ayant échoué dans les fichiers journaux ULS ou à l’aide de ULS Viewer (la visionneuse des journaux ULS).

Pour rechercher manuellement la tentative d’authentification ayant échoué

  1. Obtenez le nom du compte d’utilisateur qui génère l’échec de la tentative d’authentification.

  2. Sur le serveur exécutant SharePoint Server ou SharePoint Foundation, recherchez le dossier %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\16\LOGS ou %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\15\LOGS.

  3. Dans le dossier LOGS, cliquez sur Date de modification pour trier le dossier par date, la date la plus récente se trouvant en haut.

  4. Réessayez l’authentification.

  5. Dans la fenêtre du dossier LOGS, double-cliquez sur le fichier journal en haut de la liste pour l’ouvrir dans le Bloc-notes.

  6. Dans le Bloc-notes, cliquez sur Edition, sur Rechercher, tapez Authentification Autorisation ou Authentification basée sur les revendications, puis cliquez sur Suivant.

  7. Cliquez sur Annuler et lisez le contenu de la colonne Message.

Pour utiliser ULS Viewer, téléchargez-le sur ULS Viewer et enregistrez le dossier sur le serveur qui exécute SharePoint Server ou SharePoint Foundation. Une fois l’installation terminée, suivez les étapes suivantes pour localiser la tentative d’authentification ayant échoué.

Pour rechercher la tentative d’authentification ayant échoué à l’aide de ULS Viewer

  1. Sur le serveur qui exécute SharePoint Server ou SharePoint Foundation, double-cliquez sur Ulsviewer dans le dossier correspondant.

  2. Dans ULS Viewer, cliquez sur File (Fichier), pointez sur Open From (Ouvrir à partir de), puis cliquez sur ULS.

  3. Dans la boîte de dialogue Configurer le flux du runtime ULS, vérifiez que le dossier %CommonProgramFiles%\Common Files\Microsoft Shared\Web Server Extensions\16\LOGS folder ou \Common Files\Microsoft Shared\Web Server Extensions\15\LOGS folder est spécifié dans Utiliser le flux ULS du répertoire du fichier journal par défaut. Dans le cas contraire, cliquez sur Utiliser l’emplacement du répertoire pour les flux en temps réel et spécifiez le dossier %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\16\LOGS folder ou \Microsoft Shared\Web Server Extensions\15\LOGS folder dans Emplacement du fichier journal.

    Remplacez %CommonProgramFiles% par la valeur de la variable de l’environnement CommonProgramFiles du serveur exécutant SharePoint Server ou SharePoint Foundation. Par exemple, si l’emplacement est le lecteur C, %CommonProgramFiles% est défini sur C:\Program Files\Common Files.

  4. Cliquez sur OK.

  5. Cliquez sur Edit (Edition), puis sur Modify Filter (Modifier un filtre).

  6. Dans la boîte de dialogue Filter by (Filtrer par), dans Field (Champ), cliquez sur Category (Catégorie).

  7. Dans le champ Value (Valeur), tapez Authentication Authorization ou Claims Authentication, puis cliquez sur OK.

  8. Répétez la tentative d’authentification.

  9. Dans la fenêtre ULS Viewer, double-cliquez sur les lignes affichées pour consulter la partie Message.

Dans la zone de codage des revendications de la partie Message pour les demandes non OAuth, vous pouvez déterminer la méthode d’authentification et l’identité utilisateur codée à partir de la chaîne de revendications codées (par exemple : i:0#.w|contoso\chris). Pour plus d’informations, voir Codage des revendications SharePoint 2013 et SharePoint 2010.

Étape 2 : Vérifier la configuration requise

Pour déterminer la manière dont une application web ou une zone est configurée pour prendre en charge une ou plusieurs méthodes d’authentification basée sur les revendications, utilisez le le site Web Administration centrale de SharePoint.

Pour vérifier la configuration de l’authentification pour une application web ou une zone

  1. Dans l’Administration centrale, cliquez sur Gestion des applications dans la barre de lancement rapide, puis sur Gérer les applications web.

  2. Cliquez sur le nom de l’application web à laquelle l’utilisateur tente d’accéder et, dans le groupe Sécurité du ruban, cliquez sur Fournisseurs d’authentification.

  3. Dans la liste des fournisseurs d’authentification, cliquez sur la zone appropriée (par exemple, Par défaut).

  4. Dans la boîte de dialogue Modifier l’authentification, dans la section Types d’authentification basée sur les revendications, vérifiez les paramètres de l’authentification basée sur les revendications.

    • Pour l’authentification basée sur les revendications Windows, vérifiez que les options Activer l’authentification Windows et Authentification Windows intégrée sont sélectionnées, et que NTLM ou Négociation (Kerberos) est sélectionné selon les besoins. Sélectionnez Authentification de base si nécessaire.

    • Pour l’authentification par formulaire, vérifiez que l’option Activer l’authentification par formulaire est sélectionnée. Vérifiez les valeurs des champs Nom du fournisseur d’appartenances ASP.NET et Nom du gestionnaire de rôles ASP.NET. Ces valeurs doivent correspondre à celles du fournisseur d’appartenances et du rôle que vous avez configurées dans vos fichiers web.config pour le le site Web Administration centrale de SharePoint, l’application web et les services web SharePoint\SecurityTokenServiceApplication. Pour plus d’informations, voir Configurer l’authentification basée sur les formulaires pour une application web basée sur les revendications dans SharePoint 2013.

    • Pour l’authentification basée sur les revendications SAML, vérifiez que l’option Fournisseur d’identité approuvé et le nom du fournisseur d’identité approprié sont sélectionnés. Pour plus d’informations, voir Configurer l’authentification basée sur les revendications SAML avec les services ADFS dans SharePoint 2013.

    • Dans la section URL de page de connexion, vérifiez l’option de la page de connexion. Pour obtenir une page de connexion par défaut, Page de connexion par défaut doit être sélectionné. Pour une page de connexion personnalisée, vérifiez l’URL spécifiée. Pour ce faire, copiez l’URL et essayez d’y accéder dans un navigateur web.

  5. Cliquez sur Enregistrer pour enregistrer les modifications des paramètres d’authentification.

  6. Répétez la tentative d’authentification. Pour l’authentification par formulaire ou SAML, la page de connexion attendue s’affiche-t-elle avec les options de connexion appropriées ?

  7. Si l’authentification échoue encore, vérifiez les journaux ULS pour déterminer si la tentative d’authentification est la même avant et après la modification de la configuration d’authentification.

Étape 3 : Autres éléments à vérifier

Après avoir vérifié les fichiers journaux et la configuration de l’application web, vérifiez les éléments suivants :

  • Le navigateur web de l’ordinateur client web prend en charge les revendications. Pour plus d’informations, reportez-vous à Planification de la prise en charge du navigateur dans SharePoint Server 2016.

  • Pour l’authentification basée sur les revendications Windows, vérifiez ce qui suit :

    • L’ordinateur à partir duquel l’utilisateur émet la tentative d’authentification fait partie du même domaine que celui du serveur qui héberge l’application web SharePoint ou d’un domaine approuvé par le serveur hôte.

    • L’ordinateur à partir duquel l’utilisateur émet la tentative d’authentification est connecté au domaine de ses services de domaine Active Directory. Tapez nltest /dsgetdc: /force à l’invite de commandes ou dans SharePoint Management Shell sur l’ordinateur client web pour vérifier qu’il a accès à un contrôleur de domaine. Si aucun contrôleur de domaine n’est indiqué, réparez le problème de détectabilité et de connectivité entre l’ordinateur client web et un contrôleur de domaine des services de domaine Active Directory.

    • Le serveur exécutant SharePoint Server ou SharePoint Foundation est connecté à son domaine AD DS. Tapez nltest /dsgetdc: /force à l’invite de commandes ou dans SharePoint Management Shell sur le serveur exécutant SharePoint Server ou SharePoint Foundation pour vérifier qu’il a accès à un contrôleur de domaine. Si aucun contrôleur de domaine n’est indiqué, réparez le problème de détectabilité et de connectivité entre le serveur exécutant SharePoint Server ou SharePoint Foundation et un contrôleur de domaine AD DS.

  • Pour l’authentification par formulaire, vérifiez ce qui suit :

    • Les informations d’identification de l’utilisateur pour le fournisseur de rôles et d’appartenances ASP.NET configuré sont correctes.

    • Les systèmes hébergeant le fournisseur d’appartenances et de rôles sont disponibles sur le réseau.

    • Les pages de connexion personnalisées recueillent et acheminent correctement les informations d’identification de l’utilisateur. Pour le tester, configurez l’application web de sorte qu’elle utilise temporairement la page de connexion par défaut et vérifiez qu’elle fonctionne.

  • Pour l’authentification basée sur les revendications SAML, vérifiez ce qui suit :

    • Les informations d’identification de l’utilisateur pour le fournisseur d’identité configuré sont correctes.

    • Les systèmes qui agissent en tant que fournisseur de fédération (comme les services ADFS) et le fournisseur d’identité (comme les services de domaine Active Directory ou un fournisseur d’identité tiers) sont disponibles sur le réseau.

    • Les pages de connexion personnalisées recueillent et acheminent correctement les informations d’identification de l’utilisateur. Pour le tester, configurez l’application web de sorte qu’elle utilise temporairement la page de connexion par défaut et vérifiez qu’elle fonctionne.

Étape 4 : Utiliser un outil de débogage web pour surveiller et analyser le trafic web

Utilisez un outil tel que HttpWatch ou Fiddler pour analyser les types de trafic HTTP suivants :

  • Entre l’ordinateur client web et le serveur exécutant SharePoint Server ou SharePoint Foundation

    Par exemple, vous pouvez surveiller les messages de redirection HTTP envoyés par le serveur exécutant SharePoint Server ou SharePoint Foundation pour indiquer à l’ordinateur client web l’emplacement d’un serveur de fédération (comme les services ADFS).

  • Entre l’ordinateur client web et le serveur de fédération (comme les services ADFS)

    Par exemple, vous pouvez surveiller les messages HTTP envoyés par l’ordinateur client web, ainsi que les réponses du serveur de fédération, susceptibles de contenir des jetons de sécurité et leurs revendications.

Notes

Si vous utilisez Fiddler, la tentative d’authentification peut échouer après trois demandes d’invite d’authentification. Pour éviter ce comportement, voir Utilisation de Fiddler avec SAML et SharePoint pour franchir la limite des trois invites d’authentification.

Étape 5 : Capturer et analyser le trafic réseau d’authentification

Utilisez un outil de trafic réseau, comme Moniteur réseau 3.4, pour capturer et analyser le trafic entre l’ordinateur client web, le serveur exécutant SharePoint Server ou SharePoint Foundation et les systèmes sur lesquels SharePoint Server ou SharePoint Foundation s’appuient pour l’authentification basée sur les revendications.

Notes

Dans la plupart des cas, l’authentification basée sur les revendications utilise des connexions HTTPS (Hypertext Transfer Protocol Secure), qui chiffrent les messages envoyés entre ordinateurs. Vous ne pouvez pas voir le contenu des messages chiffrés avec un outil de trafic réseau sans l’aide d’un complément ou d’une extension. Par exemple, pour le Moniteur réseau, vous devez installer et configurer l’outil Network Monitor Decryption Expert. Vous pouvez aussi choisir une méthode plus simple de déchiffrement des messages HTTPS en utilisant un outil comme Fiddler sur le serveur hébergeant SharePoint Server ou SharePoint Foundation, qui peut créer des rapports sur les messages HTTP non chiffrés.

Une analyse du trafic réseau peut révéler ce qui suit :

  • L’ensemble exact de protocoles et messages envoyés entre les ordinateurs impliqués dans le processus d’authentification basée sur les revendications. Les messages de réponse peuvent contenir des informations sur les conditions d’erreur, que vous pouvez utiliser pour déterminer les autres étapes de résolution des problèmes.

  • Si les messages de demande sont associés à des réponses. Si plusieurs messages de demande envoyés ne reçoivent pas de réponse, le trafic réseau n’atteint peut-être pas sa destination. Dans ce cas, recherchez les éventuels problèmes pendant l’acheminement des paquets, la présence d’appareils de filtrage des paquets (comme un pare-feu) dans le chemin d’accès ou un filtrage de paquets au niveau de la destination (comme un pare-feu local).

  • Si plusieurs méthodes de revendications ont été essayées et qu’elles ont toutes échoué.

Pour l’authentification basée sur les revendications Windows, vous pouvez capturer et analyser le trafic entre les ordinateurs suivants :

  • l’ordinateur client web et le serveur exécutant SharePoint Server ou SharePoint Foundation ;

  • le serveur exécutant SharePoint Server ou SharePoint Foundation et son contrôleur de domaine.

Pour l’authentification par formulaire, vous pouvez capturer et analyser le trafic entre les ordinateurs suivants :

  • l’ordinateur client web et le serveur exécutant SharePoint Server ou SharePoint Foundation ;

  • le serveur exécutant SharePoint Server ou SharePoint Foundation et le fournisseur d’appartenances et de rôles ASP.NET.

Pour l’authentification basée sur les revendications SAML, vous pouvez capturer et analyser le trafic entre les ordinateurs suivants :

  • l’ordinateur client web et le serveur exécutant SharePoint Server ou SharePoint Foundation ;

  • l’ordinateur client web et son fournisseur d’identité (comme un contrôleur de domaine des services de domaine Active Directory) ;

  • l’ordinateur client web et le fournisseur de fédération (comme les services ADFS).

See also

Configurer l’authentification basée sur les formulaires pour une application web basée sur les revendications dans SharePoint 2013
Configurer l’authentification basée sur les revendications SAML avec les services ADFS dans SharePoint 2013