Résoudre les problèmes de filtrage des autorisations SharePoint dans Recherche Azure AI (préversion)

Utilisez cet article si le filtrage d’autorisation au moment de la requête pour le contenu indexé SharePoint retourne des résultats manquants ou inattendus, ou si une requête filtrée par autorisation échoue.

Prerequisites

• Un index alimenté par l’indexeur SharePoint dans Microsoft 365 avec l’ingestion des ACL configurée.
• Filtrage des permissions à l’exécution de la requête configuré comme décrit dans l’application des ACL et du RBAC à l’exécution de la requête.
• Version 2026-08-01-preview de l’API REST ou package de sdk en préversion équivalent lorsque vous utilisez des groupes de sites SharePoint.
• Accès à la définition d’index, à l’état de l’indexeur généré ou explicite et aux autorisations de SharePoint pour un utilisateur de test.
• Contributeur de données d’index de recherche ou autorisation de lecture élevée équivalente si vous devez comparer les résultats filtrés et non filtrés.

Suivez l’arbre de décision de résolution des problèmes

Effectuez ces vérifications dans l’ordre. Arrêtez lorsque le résultat observé identifie la configuration ou l’autorisation qui a besoin de correction.

1. Confirmer que l’échec se produit au moment de la requête

Cet article traite du filtrage des autorisations une fois que le contenu SharePoint et les métadonnées d’ACL sont indexés.

• Si la création d’une source de données ou l’exécution d’un indexeur signale Invalid AAD tenant, suivez la procédure de correction du locataire Microsoft Entra.
• Si vous devez corriger TenantId, l’authentification ou la chaîne de connexion de la source de données, consultez Configurer l’indexeur SharePoint dans Microsoft 365.
• Si UserIds, GroupIds ou SharePointSiteUrl sont manquants pendant l’indexation, utilisez le tableau de résolution des problèmes d’ingestion des ACL.

Continuez ici uniquement lorsque des métadonnées d’autorisation indexées existent et que le symptôme se produit lorsque vous l’interrogez.

2. Identifier les trois identités

Enregistrez l’identité qui remplit chaque rôle. Ne remplacez pas un identificateur par un autre.

3. Vérifier la configuration du filtre d’autorisation

Comparez l’index, l’indexeur et les objets générés avec leurs articles associés.

1. Vérifiez que l’index a permissionFilterOption défini sur enabled.
2. Vérifiez que UserIds et GroupIds ont les valeurs permissionFilter correctes.
3. Pour les groupes de sites SharePoint, vérifiez que l’index comporte sharePointConnectorAppRegistration et un champ SharePointSiteUrl avec sharepointSiteUrl: true.
4. Vérifiez que chaque document ou bloc indexé contient les champs d’autorisation applicables. Si l’ensemble de compétences utilise des projections d’index, vérifiez que les champs ACL se trouvent dans indexProjections.mappings.

Si une valeur est absente, revenez à Configurer votre service de recherche pour l’ingestion des ACL et l’application au moment de la requête.

4. Vérifiez le jeton de requête en toute sécurité

Ne connectez jamais, collez-les dans une demande de support ou partagez un jeton d’accès complet. Décoder uniquement la charge utile du jeton localement, et assainir les identificateurs avant de capturer les données de diagnostic.

1. Vérifiez que la requête inclut x-ms-query-source-authorization avec un jeton délégué valide pour l’utilisateur de test.
2. Décodez localement le contenu utile et confirmez que oid identifie l’utilisateur de test prévu. Enregistrez une valeur désinfectée telle que <test-user-object-id>.
3. Réauthentifier l’utilisateur et réessayer si le jeton est manquant ou expiré.

Si le jeton utilisateur est omis, le contenu protégé par l’autorisation n’est pas retourné. L’en-tête Authorization seul ne remplace x-ms-query-source-authorizationpas .

5. Vérifier les autorisations Microsoft Entra

1. Vérifiez que les éléments indexés UserIds ou GroupIds contiennent l’ID d’objet Microsoft Entra attendu. Utilisez une requête de lecture avec élévation de privilèges uniquement pour cette comparaison de diagnostic.
2. Vérifiez que l’utilisateur de test a une affectation directe ou qu’il accède au groupe Microsoft Entra assigné via une appartenance transitive à un groupe Microsoft Entra.
3. Si le groupe Microsoft Entra est imbriqué dans un groupe SharePoint, modifiez l’affectation. Cette relation mixte n’est pas développée et peut entraîner des résultats manquants. Ajoutez l’utilisateur directement au groupe SharePoint, ou accordez des autorisations via une attribution de groupe Microsoft Entra prise en charge.

Pour connaître la limite de prise en charge exacte, consultez les relations de groupe prises en charge.

6. Vérifier les autorisations de groupe de sites SharePoint

Effectuez cette étape lorsque l’ACL du document dépend d’un groupe de sites propriétaires, membres, visiteurs ou personnalisé SharePoint.

1. Utilisez une requête en lecture élevée pour confirmer que GroupIds contient l’ID de groupe attendu avec le préfixe spg: et que SharePointSiteUrl identifie le site source.
2. Vérifiez que l’utilisateur de test est un membre direct de ce groupe SharePoint.
3. Vérifiez que le sharePointConnectorAppRegistration de l’index utilise les identifiants et les autorisations requis par la prise en charge des groupes SharePoint.

Si les champs indexés sont vides ou obsolètes, corrigez l’ingestion ou synchronisez les autorisations de SharePoint avant de retester la requête.

7. Vérifiez la demande de requête

1. Utilisez la version 2026-08-01-preview de l’API REST ou un package SDK en préversion équivalent pour les filtres d’autorisation des groupes de sites SharePoint.
2. Confirmez que Authorization authentifie un principal pouvant interroger l’index.
3. Vérifiez que x-ms-query-source-authorization contient le jeton de l’utilisateur de test délégué.
4. Réessayez la même requête sans filtres ou modifications de classement non liées afin de pouvoir isoler le comportement des autorisations.

Utilisez l’exemple de requête général comme propriétaire de la forme de requête. N’incluez pas de tokens complets dans les requêtes enregistrées ou les journaux.

8. Comparer les résultats attendus et réels

1. Choisissez un document que l'utilisateur de test peut accéder et un document que l'utilisateur ne peut pas accéder dans SharePoint.
2. Exécutez la requête filtrée par autorisation en tant qu’utilisateur de test et enregistrez uniquement les clés de document ou d’autres identificateurs non-secret.
3. Exécutez une requête de lecture avec élévation de privilèges et comparez les valeurs stockées UserIds, GroupIds et SharePointSiteUrl avec les autorisations de la source.
4. Si la lecture en mode privilégié renvoie le document attendu, mais que la requête de l’utilisateur ne le fait pas, concentrez-vous sur le jeton utilisateur et la résolution des groupes. Si même la lecture avec élévation de privilèges ne le détecte pas, concentrez-vous sur l’ingestion, les mappages et la synchronisation des ACL.

La lecture en mode privilégié sert à des fins d’investigation. Ne l’utilisez pas pour retourner des résultats illimités aux utilisateurs finaux.

9. Capturer les détails de corrélation des demandes

Si la requête échoue toujours, capturez la version de l’API, l’horodatage UTC, le corps de la requête nettoyé, l’état HTTP, les en-têtes de réponse et toute requête ou ID de corrélation retourné par le service. Incluez le nom de l’index et indiquez si le même document apparaît lors d’une lecture en mode privilégié.

Supprimez les jetons d’accès, les clés API, les secrets, les noms d’utilisateur et les URL spécifiques au locataire avant de partager des diagnostics avec Support Microsoft.

Contenu connexe

• Application des ACL et RBAC au moment de la requête
• Utiliser un indexeur SharePoint pour ingérer des métadonnées d’autorisation
• Configurer le SharePoint dans Microsoft 365 indexeur