Устранение неполадок с фильтрацией разрешений SharePoint в Поиск с использованием ИИ Azure (предварительная версия)

Используйте эту статью, если фильтрация разрешений во время запроса для индексированного SharePoint содержимого возвращает отсутствующие или непредвиденные результаты или если запрос с фильтрацией разрешений завершается ошибкой.

Необходимые условия

• Индекс, заполненный индексатором SharePoint в Microsoft 365с настроенным приемом списков управления доступом (ACL).
• Фильтрация прав доступа на этапе запроса, настроенная, как описано в разделе Контроль ACL и RBAC на этапе запроса.
• Версия REST API или эквивалентная предварительная версия 2026-08-01-preview пакета SDK при использовании групп сайтов SharePoint.
• Доступ к определению индекса, созданному или явному состоянию индексатора и разрешениям SharePoint для тестового пользователя.
• Участник данных индекса поиска или эквивалентное разрешение на чтение с повышенными привилегиями, если необходимо сравнить отфильтрованные и нефильтрованные результаты.

Следуйте дереву принятия решений по устранению неполадок

Выполните эти проверки по порядку. Остановитесь, когда по полученному результату станет ясно, какую конфигурацию или какие права доступа нужно исправить.

1. Убедитесь, что сбой возникает во время запроса

В этой статье рассматривается фильтрация разрешений после индексирования содержимого SharePoint и метаданных ACL.

• Если при создании источника данных или запуске индексатора появляется сообщение Invalid AAD tenant, выполните действия по устранению проблемы в арендаторе Microsoft Entra.
• Если необходимо исправить TenantId, аутентификацию или строку подключения к источнику данных, см. раздел Настройка индексатора SharePoint в Microsoft 365.
• Если UserIds, GroupIds или SharePointSiteUrl отсутствуют во время индексирования, используйте таблицу устранения неполадок при приеме ACL.

Продолжайте работу здесь только если существуют индексированные метаданные разрешений и симптом возникает при их запросе.

2. Определите три идентификатора

Запишите, какая учетная запись выполняет каждую роль. Не заменяйте один идентификатор другим.

3. Проверьте конфигурацию фильтра разрешений

Сравните индекс, индексер и созданные объекты с соответствующими статьями-владельцами.

1. Убедитесь, что для индекса permissionFilterOption задано значение enabled.
2. Подтвердите, что UserIds и GroupIds имеют правильные значения permissionFilter.
3. Для групп сайтов в SharePoint убедитесь, что индекс содержит sharePointConnectorAppRegistration и поле SharePointSiteUrl с sharepointSiteUrl: true.
4. Убедитесь, что каждый индексируемый документ или блок содержит соответствующие поля разрешений. Если набор навыков использует проекции индексов, убедитесь, что поля ACL находятся в indexProjections.mappings.

Если какое-либо значение отсутствует, вернитесь к разделу Настройка службы поиска для приёма ACL и применения во время выполнения запроса.

4. Безопасно проверьте токен запроса

Никогда не записывайте в журнал, не вставляйте в запрос в службу поддержки и не передавайте токен полного доступа. Декодируйте локально только полезную нагрузку токена и очищайте идентификаторы перед сохранением диагностического вывода.

1. Убедитесь, что запрос включает x-ms-query-source-authorization с текущим делегированным токеном для тестового пользователя.
2. Декодируйте полезную нагрузку локально и подтвердите, что oid указывает на нужного тестового пользователя. Запишите санизированное значение, например <test-user-object-id>.
3. Повторно выполните проверку подлинности пользователя и повторите попытку, если маркер отсутствует или истек.

Если маркер пользователя опущен, содержимое, защищенное разрешениями, не возвращается. Заголовок Authorization не заменяет x-ms-query-source-authorization.

5. Проверка разрешений Microsoft Entra

1. Убедитесь, что индексированные UserIds или GroupIds содержат ожидаемый идентификатор объекта Microsoft Entra. Используйте запрос с повышенными привилегиями для чтения только для этого диагностического сравнения.
2. Убедитесь, что тестовый пользователь имеет прямое назначение или входит в назначенную группу Microsoft Entra через транзитивное членство в группах Microsoft Entra.
3. Если группа Microsoft Entra вложена в группу SharePoint, измените назначение. Эта смешанная связь не расширяется и может привести к отсутствием результатов. Добавьте пользователя непосредственно в группу SharePoint или предоставьте права доступа с помощью поддерживаемого назначения группы Microsoft Entra.

Точные границы поддержки см. в разделе "Поддерживаемые связи групп".

6. Проверьте разрешения группы сайтов SharePoint

Выполните этот шаг, если ACL документа зависит от группы сайта SharePoint «Владельцы», «Участники», «Посетители» или настраиваемой группы сайта SharePoint.

1. Используйте запрос на чтение с повышенными привилегиями, чтобы подтвердить, что GroupIds содержит ожидаемый идентификатор группы с префиксом spg:, а SharePointSiteUrl указывает на исходный сайт.
2. Убедитесь, что тестовый пользователь является прямым членом этой группы SharePoint.
3. Убедитесь, sharePointConnectorAppRegistration что индекс использует идентификаторы и разрешения, необходимые для поддержки групп SharePoint.

Если индексированные поля пустые или устаревшие, исправьте прием или синхронизируйте разрешения SharePoint перед повторной проверкой запроса.

7. Проверка запроса

1. Используйте версию REST API 2026-08-01-preview или эквивалентный пакет SDK предварительной версии для фильтров разрешений группы сайтов SharePoint.
2. Убедитесь, что Authorization выполняет проверку подлинности субъекта, который может выполнять запросы к индексу.
3. Убедитесь, что x-ms-query-source-authorization содержит делегированный токен тестового пользователя.
4. Повторите тот же запрос без связанных фильтров или изменений ранжирования, чтобы можно было изолировать поведение разрешений.

Используйте общий пример запроса в качестве владельца формы запроса. Не включайте полные токены в сохранённые запросы или логи.

8. Сравнение ожидаемых и фактических результатов

1. Выберите один документ, к который тестовый пользователь может получить доступ, и один документ, к который пользователь не может получить доступ в SharePoint.
2. Запустите отфильтрованный разрешением запрос от имени тестового пользователя и запишите только ключи документов или другие несекретные идентификаторы.
3. Запустите запрос на чтение с повышенными привилегиями и сравните сохранённые значения UserIds, GroupIds и SharePointSiteUrl с правами доступа источника.
4. Если чтение с повышенными привилегиями возвращает ожидаемый документ, а пользовательский запрос — нет, сосредоточьтесь на токене пользователя и определении групповой принадлежности. Если чтение с повышенными правами доступа тоже не находит его, сосредоточьтесь на загрузке данных, сопоставлениях и синхронизации ACL.

Чтение с повышенными привилегиями предназначено для исследования. Не используйте его для возврата неограниченных результатов конечным пользователям.

9. Сбор сведений о корреляции запросов

Если запрос по-прежнему завершается ошибкой, сохраните версию API, метку времени UTC, очищенное тело запроса, код состояния HTTP, заголовки ответа и любой идентификатор запроса или корреляции, возвращенный службой. Укажите имя индекса и отображается ли тот же документ при чтении с повышенными привилегиями.

Удалите маркеры доступа, ключи API, секреты, имена пользователей и URL-адреса для конкретного клиента, прежде чем предоставлять доступ к диагностике с служба поддержки Майкрософт.

Связанные материалы

• Применение ACL и RBAC в момент выполнения запроса
• Использование индексатора SharePoint для приема метаданных разрешений
• Настройка SharePoint в индексаторе Microsoft 365