Подготовка приложений в карантинном состоянии

  • Статья

Служба подготовки Microsoft Entra отслеживает работоспособность конфигурации. Она также помещает неработоспособные приложения в состояние "карантина". Если большинство или все вызовы, выполненные в целевую систему, постоянно завершаются сбоем, задание подготовки помечается как помещенное в карантин. Пример сбоя — это ошибка, полученная из-за недопустимых учетных данных администратора.

Что происходит в карантине:

  • Частота добавочных циклов постепенно уменьшается до одного раза в день.
  • Задание подготовки выходит из карантина после исправления всех ошибок, послуживших его причиной, после чего начнется следующий цикл синхронизации.
  • Если задания подготовки остается в карантине более четырех недель, оно отключается (больше не запускается).

Как я узнаю, что мое приложение в карантине?

Существует три способа проверить, находится ли приложение в карантине:

  • В Центре администрирования Microsoft Entra перейдите к приложению Identity>Applications>Enterprise<>Application Name>>Provisioning и просмотрите индикатор выполнения сообщения о карантине.

    Provisioning status bar showing quarantine status

  • В Центре администрирования Microsoft Entra перейдите к фильтру "Мониторинг удостоверений" и "Журналы> аудита работоспособности>>" по действиям: карантин и просмотр журнала карантина. Индикатор выполнения, как описано выше, показывает, находится ли подготовка в карантине. В журналах аудита отображается история помещения в карантин для приложения.

  • Используйте запрос Microsoft Graph Get synchronizationJob, чтобы программно получить состояние задания подготовки:

        GET https://graph.microsoft.com/beta/servicePrincipals/{id}/synchronization/jobs/{jobId}/

  • Проверьте электронную почту. Когда приложение помещается в карантин, отправляется одноразовое уведомление по электронной почте. При изменении причины карантина отправляется обновленное сообщение электронной почты с новой причиной помещения в карантин. Если вы не видите сообщение электронной почты, сделайте следующее.

    • Убедитесь, что в конфигурации подготовки для приложения указан допустимый адрес электронной почты для уведомлений.
    • Убедитесь, что в папке "Входящие" электронной почты для уведомлений отсутствует фильтрация нежелательной почты.
    • Убедитесь, что вы не отменили подписку на сообщения электронной почты.
    • Проверьте сообщения электронной почты от azure-noreply@microsoft.com

Почему мое приложение находится в карантине?

Ниже приведены распространенные причины, по которым ваше приложение может быть помещено на карантин.

Description Рекомендуемое действие
Проблемы с соответствием SCIM: возвращен ответ HTTP/404 Не найден, а не ожидаемый ответ HTTP/200 OK. В этом случае служба подготовки Microsoft Entra сделала запрос к целевому приложению и получила неожиданный ответ. Проверьте раздел учетных данных администратора. Проверьте, требуется ли для приложения указать URL-адрес клиента, а также правильность URL-адреса. Если вы не видите проблемы, обратитесь к разработчику приложения, чтобы убедиться, что его служба соответствует SCIM. https://tools.ietf.org/html/rfc7644#section-3.4.2
Недопустимые учетные данные: при попытке авторизовать доступ к целевому приложению мы получили ответ от целевого приложения, который указывает, что учетные данные недопустимы. Перейдите к разделу учетных данных администратора в пользовательском интерфейсе конфигурации подготовки и снова авторизуйте доступ с действительными учетными данными. Если приложение находится в коллекции, ознакомьтесь с руководством по настройке приложения, чтобы выполнить необходимые действия.
Дублирование ролей: роли, импортированные из некоторых приложений, таких как Salesforce и Zendesk, должны быть уникальными. Перейдите к манифесту приложения в Центре администрирования Microsoft Entra и удалите дубликат роли.

Запрос Microsoft Graph для получения состояния задания подготовки показывает следующую причину для карантина:

  • EncounteredQuarantineException указывает, что были предоставлены недопустимые учетные данные. Службе подготовки не удается установить соединение между исходной системой и целевой системой.
  • EncounteredEscrowProportionThreshold указывает, что подготовка превысила пороговое значение. Это состояние возникает при сбое более 40 % событий подготовки. Дополнительные сведения см. в разделе сведения о депонировании пороговых значений ниже.
  • QuarantineOnDemand означает, что мы обнаружили проблемы с приложением и вручную отправили его в карантин.

Депонированные пороговые значения

Если соблюдено пропорциональное пороговое значение, задание подготовки перейдет в карантин. Эта логика может быть изменена, но работает примерно так, как описано ниже:

Задание может переключиться в карантин независимо от количества сбоев для таких проблем, как учетные данные администратора или соответствие SCIM. Однако в общем случае 5000 ошибок — это минимальный порог, чтобы начать оценку необходимости помещения в карантин из-за слишком большого количества сбоев. Например, задание с 4000 сбоями не будет отправлено в карантин. Однако задание с 5000 сбоями начнет оценку. Для оценки используются следующие критерии.

  • Если более 40 % событий подготовки завершаются сбоем или существует более 40 000 сбоев, задание подготовки перейдет в карантин. Ошибки ссылок не учитываются как часть порогового значения 40 % или 40 000. Например, сбой обновления руководителя или члена группы является ошибкой ссылки.
  • Задание, в котором 45 000 пользователей не удалось подготовить, попадет в карантин, так как оно превышает пороговое значение 40 000.
  • Задание, в котором 30 000 пользователей не прошло подготовку, а 5000 подготовлены успешно, привело к появлению карантина, так как оно превышает порог 40 % и минимум 5000.
  • Задание с 20 000 ошибками и 100 000 успешными случаями не перейдет в карантин, так как оно не превышает пороговое значение сбоя 40 % или не превышает максимально возможный сбой 40 000.
  • Существует абсолютное пороговое значение в 60 000 сбоев, которое включает ошибки ссылок и другие ошибки. Например, не удалось подготовить 40 000 пользователей и обновить 21 000 руководителей. Общий объем составляет 61 000 ошибок и превышает ограничение в 60 000.

Длительность повторных попыток

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

После сбоя первая повторная попытка произойдет через 6 часов.

  • Второе повторение происходит через 12 часов после первого сбоя.
  • Третья повторная попытка происходит через 24 часа после первого сбоя.

После 3-го повтора будут повторяться каждые 24 часа. Повторные попытки будут продолжаться в течение 28 дней после первого сбоя, после которого запись депонирования удаляется и задание отключено.
Если любой из описанных выше повторных попыток получает успешный ответ, задание автоматически выходит из карантина и возобновляет регулярное поведение синхронизации.

Как мне достать мое приложение из карантина?

Сначала устраните проблему, которая привела к помещению приложения в карантин.

  • Проверьте параметры подготовки приложения, чтобы убедиться, что введены действительные учетные данные администратора. Идентификатор Microsoft Entra должен установить доверие с целевым приложением. Убедитесь, что введены допустимые учетные данные, а учетная запись имеет необходимые разрешения.

  • Просмотрите журналы подготовки, чтобы исследовать ошибки, приводящие к карантину, и устраните ошибку. Перейдите в журналы подготовки корпоративных приложений>Microsoft Entra ID>(предварительная версия) в разделе действий.

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

  • Чтобы перезапустить задание подготовки, используйте Центр администрирования Microsoft Entra. На странице Подготовка приложения выберите Перезапустить подготовку. Это действие полностью перезапускает службу подготовки, которая может занять некоторое время. Будет снова выполнен полный начальный цикл, который очищает депонирование, удаляет приложение из карантина и очищает все водяные знаки. Затем служба снова оценивает всех пользователей в исходной системе и определяет, находятся ли они в области для подготовки. Это может быть полезно, если приложение находится на карантине, о чем идет речь в этой статье, или необходимо внести изменение в сопоставления атрибутов. Обратите внимание, что начальный цикл занимает больше времени, чем обычный добавочный цикл, из-за количества объектов, которые необходимо оценить. Дополнительные сведения о производительности начального и добавочного циклов см. здесь.

  • Используйте Microsoft Graph, чтобы перезапустить задание подготовки. Вы получите полный контроль над перезапусками. Вы можете очистить депонирование (чтобы перезапустить счетчик депонирования, который начисляется в сторону состояния карантина), очистить карантин (чтобы удалить приложение из карантина) или снять пределы. Используйте следующий запрос:

        POST /servicePrincipals/{id}/synchronization/jobs/{jobId}/restart

Замените "{ID}" значением идентификатора приложения и замените "{jobId}" идентификатором задания синхронизации.