Этот плейбук описывает шаги для решения проблем, когда предоставление SCIM по расписанию не удалось.
Обзор
Синхронизация SCIM является критически важной для предоставления пользователей в CMA, что обеспечивает беспроблемное подключение и стабильный доступ к ресурсам. Частота синхронизации зависит от используемого поставщика идентификационных данных (IdP), как описано в Правило предоставления SCIM.
Когда предоставление SCIM не удалось, вновь созданные пользователи могут не иметь возможности подключиться или получить доступ к необходимым услугам, и политика безопасности может быть применена некорректно. Чтобы обеспечить быструю обнаружение и решение, история XOps автоматически создается каждый раз, когда происходит сбой предоставления между IdP и CMA.
При ответе на истории XOps сети важно подходить к проблеме систематически. Во-первых, убедитесь, что проблема продолжается, затем устраните её, и в конце подтвердите, что проблема решена.
Шаг 1 - Проверка сбоя синхронизации SCIM
Ниже приведены различные способы, которыми администратор Приложения управления Cato может подтвердить, что произошёл сбой синхронизации SCIM.
Использование детализации истории
История XOps будет сгенерирована, когда синхронизация SCIM закончится неудачно.
Перейдите на страницу Рабочая область Историй и используйте пресет сетевых операций, включая фильтр 'Индикация Содержит SCIM'. При необходимости, настройте временной интервал.

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

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

Когда вы прокрутите далее по детализации истории, вы найдете хронологию инцидента. Эта хронология выделяет изменения в статусе синхронизаций SCIM. На правой панели вы увидите рабочий процесс плейбука, который описывает шаги для устранения проблемы.
Использование события
Сбои синхронизации SCIM также могут быть подтверждены путем проверки соответствующих записей событий.
Чтобы просмотреть это событие, отфильтруйте панель управления событиями, установив Подтип на Правило предоставления SCIM и Действие на Не удалось. При необходимости настройте временной интервал, чтобы соответствовать времени, когда проблема возникла.

Если обнаружен сбой синхронизации SCIM, вы увидите события, аналогичные примеру, показанному ниже. Сообщение события покажет причину сбоя синхронизации. В примере, показанном ниже, это связано с "Внутренняя ошибка сервера".

Шаг 2 - Устранение проблем сбоя синхронизации SCIM
Этот раздел описывает инструменты, доступные в Cato, для структурированного подхода к устранению проблем данного типа. Хотя шаги обычно следует выполнять по порядку, результаты каждой проверки могут влиять на следующий шаг процесса.
Выполнение предоставления по требованию
Чтобы определить, была ли проблема единственным случаем, выполните предоставление по требованию с платформы IdP. Для Azure перейдите в Корпоративные приложения > Предоставление Cato Networks > Предоставление и нажмите "Предоставление по требованию".

Выберите пользователя или группу, назначенных приложению, и нажмите кнопку "Предоставление".
Если синхронизация SCIM завершится успешно, это может означать, что сбой синхронизации SCIM был единичным инцидентом. Администратор должен проверить, совпадают ли прерывания провайдеров или активности по обслуживанию Cato с временем синхронизации SCIM.
Если синхронизация SCIM также не удалась, это указывает на то, что проблема сохраняется, и синхронизация с IdP не завершена успешно. В таком случае, просмотрите любые недавние изменения конфигурации, которые могли привести к проблеме.
Просмотр изменений в журнале аудита
Просмотрите изменения на странице Журнал аудита, чтобы определить, является ли изменение конфигурации причиной этой проблемы. Этот шаг особенно важен, если запланированная синхронизация функционировала нормально, но неожиданно перестала работать.
Чтобы просмотреть любые изменения, внесенные в конфигурацию домена, отфильтруйте панель управления аудитом, установив Тип модели на Домен. При необходимости настройте временной интервал, чтобы соответствовать времени, когда проблема возникла.

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

Другим фактором, который может повлиять на соединение SCIM, являются изменения в приложении на стороне IdP. Для Azure перейдите в Корпоративные приложения > Предоставление Cato Networks и проверьте Журналы аудита и Журналы предоставления, чтобы определить, вызвало ли изменение конфигурации сбой SCIM.

Обновление учетных данных администратора
Чтобы проверить сбой учетных данных с IdP, сгенерируйте новый токен из CMA под Службы каталогов > SCIM. Нажмите "сгенерировать токен" и скопируйте новый токен.

Для Azure перейдите в Корпоративные приложения > Предоставление Cato Networks > Предоставление и разверните Предоставление > Учетные данные администратора. Введите токен, сгенерированный из CMA, и нажмите "Проверить соединение".

Если аутентификация успешна, проблема может быть связана с несоответствием токенов между IdP и CMA.
Шаг 3 - Проверка работоспособности синхронизации SCIM
После выявления и устранения проблемы, которая вызвала сбой синхронизации SCIM, убедитесь, что теперь синхронизация отображается как решённая в истории.
Использование детализации истории

ПРИМЕЧАНИЕ: Как только проблема будет решена, статус истории изменится с "Открытые" на "Мониторинг". Она останется в этом состоянии в течение следующего часа, если не произойдут дальнейшие инциденты. Для получения дополнительной информации обратитесь к Понимание колонок историй.
Хронология инцидента
Хронология инцидента отображает изменения в статусе запланированной синхронизации. Вы можете использовать ее, чтобы подтвердить, обновился ли последний статус на "Закрыто".

Создание заявок в Поддержку Cato
Если после выполнения этого плейбука проблема не решена, отправьте тикет в поддержку. Чтобы получить максимально полезный ответ на запрос, администратор должен предоставить результаты предпринятых шагов для устранения неполадок.