Увеличить устойчивость аутентификации федеративных приложений, развернутых на сайтах с совместно размещенными пользователями

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

Исторически организации могут использовать доменные службы Active Directory, развертывать контроллеры домена на каждом сайте, чтобы пользователи могли пройти проверку подлинности на локальном контроллере домена. Проверка подлинности пользователей через Microsoft Entra и подключение приложений к идентификатору Microsoft Entra с помощью протоколов федерации, таких как SAML, дает преимущества, включая многофакторную проверку подлинности и условный доступ на основе рисков. Когда приложения федеративно подключены к Microsoft Entra, пользователи проходят проверку подлинности в Microsoft Entra, который затем предоставляет маркеры, несущие утверждения и указывающие их статус аутентификации для приложений. Однако если между сайтом и Интернетом произошел перерыв в сетевом подключении, пользователи и приложения не смогут получить доступ к облачным конечным точкам Microsoft Entra. При таком разрыве подключения никакие маркеры не могут выдаваться из Microsoft Entra приложениям через этот маршрут до тех пор, пока не будет восстановлен разрыв. Пользователи уже прошли проверку подлинности в приложении и смогут подключиться к приложению, возможно, смогут продолжать использовать приложение в течение некоторого времени. Однако если приложению требуется повторно выполнить проверку подлинности, а перерыв еще не восстановлен, пользователь не сможет получить новый маркер доступа из Microsoft Entra. Кроме того, пока не будет восстановлен перерыв, любой пользователь, который ранее не подключен к приложению, также может оказаться не в состоянии использовать приложение.

Один из подходов к решению этой проблемы и обеспечение выдачи маркеров федеративным приложениям даже во время временного отключения сайта:

• Обслуживание контроллера домена Active Directory на каждом сайте
• Убедитесь, что пользователи на сайте могут пройти проверку подлинности в Active Directory или Microsoft Entra, и что одни и те же утверждения доступны обоим поставщикам удостоверений
• Настройте приложения для доверия Microsoft Entra в качестве поставщика удостоверений во время обычной работы, но в случае события отключения доверьтесь Active Directory в качестве поставщика удостоверений.

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

Альтернативный подход, описанный в этом руководстве, заключается в добавлении службы маркеров безопасности проверяющей стороны (STS), например AD FS в топологию. В этой топологии,

• Обслуживание контроллера домена Active Directory на каждом сайте
• Убедитесь, что пользователи на сайте могут пройти проверку подлинности в Active Directory или Microsoft Entra
• Настройка приложений для доверия локальной службе маркеров безопасности проверяющей стороны (STS)
• Настройте службу STS доверяющей стороны, чтобы доверять Microsoft Entra в качестве поставщика удостоверений во время штатных операций, но при разрыве соединения доверяйте Active Directory в качестве поставщика удостоверений.

В этом руководстве показано, как настроить Microsoft Entra для федеративного приложения с помощью службы STS проверяющей стороны. В обычных операциях пользователи будут проходить проверку подлинности в Microsoft Entra, и Microsoft Entra выдает маркеры для приложения. И в ситуации отключения сайта пользователи могут проходить проверку подлинности в Active Directory и получать токены для этого приложения с аналогичными утверждениями, предоставляемыми Microsoft Entra. Хотя функции Microsoft Entra, включая многофакторную проверку подлинности или условный доступ на основе рисков, не будут доступны для приложений во время отключения, пользователи по-прежнему смогут проходить проверку подлинности для доступа к этим приложениям.

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

Предпосылки

В этом руководстве используется как клиент Microsoft Entra, так и домен Active Directory. Перед началом работы убедитесь, что у вас есть одна из следующих ролей в Microsoft Entra: Cloud Application Administrator, Application Administrator. Вам также потребуются разрешения для администрирования AD.

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

• Одно или несколько приложений, каждый из которых реализует протокол федерации, например SAML, с шаблоном входа, инициированным проверяющей стороной. Дополнительные сведения см. в статье о протоколе SAML единого входа. В этом руководстве показана конфигурация, в которой, если у вас несколько приложений, один и тот же набор пользователей можно пройти проверку подлинности и авторизоваться для всех приложений. Настройка различных наборов пользователей для каждого приложения выходит за рамки этого руководства.
• Компонент удостоверения, который можно настроить для работы в качестве проверяющей стороны STS, например, в службах федерации Active Directory. В этом руководстве рассматривается использование Windows Server 2025. В качестве рекомендации по обеспечению безопасности поместите серверы федерации служб федерации Active Directory за брандмауэром и подключите их к корпоративной сети, чтобы предотвратить воздействие из Интернета. Эта практика важна, так как серверы федерации имеют полную авторизацию для предоставления маркеров безопасности. Таким образом, они должны иметь ту же защиту, что и контроллер домена. Если сервер федерации скомпрометирован, злоумышленник может выдавать маркеры полного доступа всем веб-приложениям, защищенным службами федерации Active Directory. Дополнительные сведения см. в разделе о расположении сервера федерации.
• Контроллер домена Active Directory. В рабочей среде потребуется несколько контроллеров домена, настроенных для обеспечения высокой доступности.

Приложения могут иметь другие требования, помимо этих требований к удостоверениям, например требования к хранению журналов, DNS/DHCP или другим службам сети и инфраструктуры, которые выходят за рамки этого руководства.

Обеспечение согласованности удостоверений пользователей и атрибутов в Active Directory и идентификаторе Microsoft Entra

Приложения будут ожидать получения одинаковых утверждений для пользователей в токене федерации от проверяющей стороны STS независимо от настроенного поставщика удостоверений. Чтобы проверяющая сторона STS предоставляла те же утверждения, что и ожидалось от идентификатора Microsoft Entra, даже если идентификатор Microsoft Entra недоступен, для создания утверждений должен быть источник удостоверений пользователей и их атрибуты, локальные для сайта, которые могут использоваться проверяющей стороной STS. AD FS поддерживает Windows Server Active Directory в качестве источника удостоверений и атрибуты пользователя Active Directory в качестве источника утверждений.

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

Если вы уже настроили синхронизацию пользователей из Active Directory с Microsoft Entra, перейдите к следующему разделу.

1. Включите корзину Active Directory. Функция корзины необходима для рабочих процессов жизненного цикла Microsoft Entra, чтобы иметь возможность удалять пользователей из Active Directory. Дополнительные сведения см. в разделе «Включение и управление корзиной Active Directory с помощью Центра администрирования Active Directory».

2. При необходимости расширьте схему Active Directory. Для каждого атрибута пользователя, необходимого Microsoft Entra и приложениям, которые еще не входят в схему пользователя AD, необходимо выбрать встроенный атрибут расширения пользователя. Кроме того, необходимо расширить схему Windows Server AD , чтобы иметь место для хранения этого атрибута AD. Это требование также включает атрибуты, используемые для автоматизации, например, дату приема на работу и дату увольнения сотрудника.

   Например, некоторые организации могут использовать атрибуты extensionAttribute1 и extensionAttribute2 хранить эти свойства. Если вы решили использовать встроенные атрибуты расширения, убедитесь, что эти атрибуты еще не используются другими приложениями на основе LDAP или другими приложениями, интегрированными с идентификатором Microsoft Entra. Некоторые организации создали новые атрибуты AD с именами, соответствующими их требованиям, например contosoWorkerId. Однако расширение схемы с новыми атрибутами имеет значительные последствия для управления доменами Windows Server. Дополнительные сведения см. в разделе о расширении схемы.

3. Импортируйте пользователей с их атрибутами из авторитетных источников. Если вы еще этого не сделали, настройте Microsoft Entra для подготовки работников из Workday, SuccessFactors или других источников кадров в качестве пользователей в AD. Свойства рабочих записей можно сопоставить с атрибутами пользователя в схеме AD.

4. Настройте синхронизацию между Microsoft Entra и Active Directory. Настройте синхронизацию Microsoft Entra Connect или облачную синхронизацию Microsoft Entra для синхронизации этих пользователей из AD в Microsoft Entra. Также разверните агент подготовки для выполнения задач рабочего процесса жизненного цикла учетной записи пользователя, таких как удаление пользователей из AD.

5. Расширьте схему идентификатора Microsoft Entra и настройте сопоставления из схемы Active Directory с пользовательской схемой идентификатора Microsoft Entra ID. Если вы используете синхронизацию Microsoft Entra Connect, выполните действия в Microsoft Entra Connect Sync: расширения каталогов для расширения пользовательской схемы Microsoft Entra ID добавлением атрибутов. Настройте сопоставления синхронизации Microsoft Entra Connect для атрибутов AD с атрибутами в идентификаторе Microsoft Entra.

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

6. Создайте рабочий процесс выхода, который блокирует входы. В рабочих процессах жизненного цикла Microsoft Entra настройте рабочий процесс выхода с задачей Disable user account , которая блокирует вход пользователей в локальную среду. Этот рабочий процесс может выполняться по запросу. Если вы не настроили входящий трафик подготовки из источников записей, чтобы запретить вход рабочих лиц после запланированной даты выхода, настройте рабочий процесс выхода с этой задачей для запуска на запланированные даты отпуска этих работников. Дополнительные сведения см. в разделе "Управление пользователями, синхронизированными из локальной среды".

7. Создайте процесс увольнения для удаления учетных записей пользователей. В рабочих процессах жизненного цикла Microsoft Entra настройте рабочий процесс выхода с задачей Delete user для удаления пользователя из Active Directory. Запланируйте выполнение этого рабочего потока в течение некоторого периода времени, например 30 или 90 дней, после даты начала отпуска сотрудника.

Дополнительные сведения о настройке потоков входящего трафика кадров для приложений с несколькими атрибутами см. в разделе "Планирование развертывания Microsoft Entra для подготовки пользователей".

Предоставление возможности проверки подлинности для пользователей в Active Directory

При настройке входящего обеспечения из HR-источника в AD Microsoft Entra создает пользователей в AD, как для существующих работников, которые ранее не имели учетных записей пользователей AD, так и для новых работников, которые позже присоединятся. Эти пользователи должны иметь возможность проходить проверку подлинности в AD во время отключения, а также иметь возможность проходить проверку подлинности в идентификаторе Microsoft Entra во время обычных операций. Вам потребуется запланировать выдачу учетных данных для работников, которым требуется доступ к приложениям, которые они могут использовать с AD.

Если единственными приложениями, подключенными к AD, являются те, которые настроены для обеспечения устойчивости, то одним из способов обеспечения согласованной проверки подлинности является создание пользователей в AD, а затем включение синхронизации хэша паролей для тех пользователей, которые синхронизируются с AD с Microsoft Entra. Убедитесь, что у пользователей есть пароли, заданные в AD, и они знают свой пароль в AD. Хотя они могут иметь требования к многофакторной проверке подлинности во время обычных операций, во время отключенного сетевого события они смогут пройти проверку подлинности в домене Active Directory с помощью паролей.

Другой вариант — использовать проверку подлинности на основе сертификатов (CBA) Microsoft Entra, которая позволяет Microsoft Entra проходить проверку подлинности пользователей с помощью сертификатов X.509, выданных инфраструктурой открытых ключей предприятия (PKI). AD также поддерживает проверку подлинности сертификатов, а некоторые организации выпустили смарт-карты, виртуальные смарт-карты или сертификаты программного обеспечения для своих пользователей. Если пользователи будут взаимодействовать с приложениями с устройств, поддерживающих Windows Hello для бизнеса, также рассмотрите возможность регистрации пользователей в Windows Hello для бизнеса для более надежной проверки подлинности.

Развертывание STS службы проверяющей стороны и настройка Microsoft Entra как поставщика удостоверений

Если вы еще не сделали этого, разверните AD FS или аналогичную технологию идентификации на одном или нескольких серверах Windows на сайте. Эта служба AD FS будет настроена для работы в качестве проверяющей стороны STS, поэтому не может быть той же установкой, что и другая служба AD FS, настроенная в качестве поставщика удостоверений для предоставления утверждений Microsoft Entra.

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

Затем выполните действия, описанные в руководстве по включению единого входа для корпоративного приложения с помощью службы маркеров маркеров безопасности проверяющей стороны . В этом руководстве описано, как создать представление приложения в Microsoft Entra, настроить единый вход для этого приложения из Microsoft Entra в службу STS проверяющей стороны и настроить единый вход из проверяющей стороны STS в приложение. Выполнение этого руководства проверяет, что во время обычных операций маркеры с утверждениями могут передаваться из Microsoft Entra через проверяющую сторону STS в приложение.

Настройка AD в качестве источника LDAP в проверяющей стороне STS

Затем настройте в службе stS проверяющей стороны, что Active Directory является источником утверждений для утверждений, необходимых приложениям. Ниже показано использование AD FS, но вместо этого можно использовать другую проверяющую сторону STS.

1. Войдите от имени администратора на сервере, на котором развернута служба AD FS.
2. Запустите AD FS Management.
3. AD FS В меню выберите Claims Provider Trusts.
4. Убедитесь, что есть два поставщика утверждений и Microsoft EntraActive Directoryоба включены. Поставщик утверждений Active Directory присутствует по умолчанию.
5. Выберите Active Directory и выберите Edit Claim Rules.
6. Убедитесь, что существуют правила для атрибутов LDAP, необходимых в качестве утверждений приложениями в вашей среде.
7. AD FS В меню выберите Relying Party Trusts.
8. Выберите целевое приложение и выберите Edit Claim Issuance Policy.
9. Убедитесь, что правила, касающиеся претензий, отправленных в приложения, охватывают все необходимые аспекты этих претензий. Дополнительные сведения см. в разделе "Сквозь" или "Фильтрация входящего утверждения".

Подготовка тестового пользователя AD к входу в приложение с помощью Microsoft Entra

При тестировании конфигурации следует назначить назначенного тестового пользователя, созданного в Active Directory, роли приложения в Microsoft Entra. Этот выбор пользователя AD проверяет, что пользователь может войти в приложение через Microsoft Entra и проверяющую сторону STS.

1. Определите тестового пользователя в Active Directory. Убедитесь, что вы знаете пароль этого пользователя, чтобы вы могли пройти проверку подлинности как в Active Directory, так и в Microsoft Entra.

2. Если вы недавно создали пользователя в AD, дождитесь завершения синхронизации с AD с идентификатором Microsoft Entra ID.

   Если вы используете Microsoft Entra Cloud Sync, вы можете отслеживать steadyStateLastAchievedTime свойство состояния синхронизации, извлекая задание синхронизации субъекта-службы, представляющего Microsoft Entra Cloud Sync. Если у вас нет идентификатора субъекта-службы, просмотрите схему синхронизации.

3. Войдите в Центр администрирования Microsoft Entra с учетной записью не ниже администратора облачных приложений.

4. Перейдите к Entra ID>Корпоративные приложения>Все приложения.

5. Введите имя существующего приложения в поле поиска и выберите приложение из результатов поиска.

6. В разделе Управление в меню слева выберите Свойства.

7. Убедитесь, что для входа пользователей задано значение "Да".

8. Убедитесь, что для параметра "Назначение" задано значение "Да".

9. Если вы внесли какие-либо изменения, нажмите кнопку "Сохранить".

10. В разделе "Управление " в меню слева выберите "Пользователи" и "Группы".

11. Выберите Добавить пользователя или группу.

12. Выберите "Нет".

13. В поле поиска введите имя тестового пользователя, а затем выберите пользователя и нажмите кнопку "Выбрать".

14. Выберите "Назначить ", чтобы назначить пользователя роли пользователя по умолчанию для приложения.

15. В разделе "Безопасность " в меню слева выберите условный доступ.

16. Выберите "Что если".

17. Выберите "Нет пользователя или учетной записи службы", выберите "Нет пользователя" и выберите пользователя, ранее назначенного приложению.

18. Выберите любое облачное приложение и выберите корпоративное приложение.

19. Выберите "Что если". Убедитесь, что все политики, которые будут применяться, позволяют пользователю входить в приложение.

Установка поставщика утверждений для каждого приложения в качестве Microsoft Entra

После настройки приложения в Microsoft Entra и службы STS проверяющей стороны пользователи могут войти в него. Пользователи начнут проверку подлинности в Microsoft Entra, а маркер, предоставленный Microsoft Entra, будет преобразован проверяющей стороной STS, например AD FS, в формат и утверждения, необходимые вашему приложению. Кроме того, пользователи смогут войти в систему, выполнив проверку подлинности в AD и получив токен от AD FS с аналогичными утверждениями.

В этом разделе вы настроите реляционную службу STS для предоставления Microsoft Entra в качестве поставщика удостоверений для каждого приложения в обычном режиме работы. Ниже показано использование AD FS, но вместо этого можно использовать другую проверяющую сторону STS.

1. Запустите PowerShell на сервере Windows Server, где установлен AD FS.
2. Получите список приложений с помощью команды Get-AdfsRelyingPartyTrust | ft Name,ClaimsProviderName.
3. Получите список поставщиков утверждений с помощью команды Get-AdfsClaimsProviderTrust | ft Name. Должно быть два имени, одно для Active Directory и другое для Microsoft Entra.
4. Настройте, что Microsoft Entra является единственным поставщиком утверждений для каждого приложения с помощью команды Set-AdfsRelyingPartyTrust . Например, если приложение называется appname, введите Set-AdfsRelyingPartyTrust -TargetName "appname" -ClaimsProviderName "Microsoft Entra". Повторите это для каждого приложения. Дополнительные сведения см. в разделе "Настройка списка поставщиков удостоверений на проверяющую сторону".

Проверка единого входа во время обычных операций

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

1. В частном сеансе просмотра в веб-браузере подключитесь к приложению и инициируйте процесс входа. Приложение перенаправляет веб-браузер к доверяющей стороне STS AD FS, где AD FS определяет поставщиков удостоверений, способных предоставлять необходимые утверждения.
2. В соответствии с конфигурацией, приведенной в предыдущем разделе, AD FS выберет поставщика удостоверений Microsoft Entra. AD FS перенаправляет веб-браузер в конечную точку входа Microsoft Entra, https://login.microsoftonline.com если используется глобальная служба идентификатора Microsoft Entra.
3. Войдите в Microsoft Entra с помощью удостоверения тестового пользователя, ранее настроенного в разделе подготовки тестового пользователя AD, чтобы быть готовым к входу в приложение. Затем Microsoft Entra находит корпоративное приложение на основе идентификатора сущности и перенаправляет веб-браузер в AD FS на конечную точку URL-адреса ответа, при этом веб-браузер транспортирует токен SAML.
4. AD FS проверяет, что токен SAML был выдан Microsoft Entra, а затем извлекает и преобразует утверждения из токена SAML и перенаправляет веб-браузер в приложение. Убедитесь, что приложение получило необходимые утверждения от Microsoft Entra через этот процесс.

Проверка единого входа после изменения поставщика утверждений, доверенного приложением в Active Directory

В этом разделе вы проверите, что при переключении поставщика удостоверений для приложения в Active Directory пользователи по-прежнему могут пройти проверку подлинности и войти в приложение.

1. Запустите PowerShell на сервере Windows Server, где установлен AD FS.
2. В сеансе PowerShell настройте, что Active Directory теперь является единственным поставщиком утверждений для приложения, заменив Microsoft Entra с помощью команды Set-AdfsRelyingPartyTrust. Например, если приложение называется appname, введите Set-AdfsRelyingPartyTrust -TargetName "appname" -ClaimsProviderName "Active Directory".
3. Чтобы очистить любое состояние входа в браузере, закройте любой ранее открытый сеанс приватного просмотра веб-браузера.
4. В новом сеансе приватного просмотра веб-браузера подключитесь к нему и инициируйте процесс входа. Приложение перенаправляет веб-браузер в AD FS, а AD FS определяет поставщиков удостоверений, которые могут предоставлять соответствующие утверждения.
5. На основе конфигурации на шаге 2 AD FS выберет Active Directory.
6. Войдите в AD FS с помощью учетной записи Active Directory тестового пользователя. AD FS будет проходить проверку подлинности пользователя в Active Directory.
7. AD FS преобразует атрибуты LDAP пользователя в утверждения и перенаправляет веб-браузер в приложение. Убедитесь, что приложение получило необходимые утверждения от Active Directory через этот процесс.
8. В сеансе PowerShell настройте, что Microsoft Entra снова является поставщиком утверждений для приложения, используя команду Set-AdfsRelyingPartyTrust и укажите значение -ClaimsProviderName параметра. Вы также можете разрешить всех поставщиков утверждений с помощью команды, такой как Set-AdfsRelyingPartyTrust -TargetName "appname" -ClaimsProviderName @().

Настройте, кто может входить в приложение.

Вам потребуется настроить, кто может войти в каждое приложение. AD FS и Microsoft Entra имеют разные механизмы для определения области действия токенов в своих политиках, поэтому вам может потребоваться внести изменения в обеих.

1. Ранее вы назначили тестового пользователя на роль в приложении Microsoft Entra, теперь вы можете захотеть удалить это назначение.
2. Если у вас есть несколько приложений, подключенных к одной проверяющей стороне STS, то в Microsoft Entra может быть только один объект приложения, представляющий все эти приложения. Для назначений ролей можно использовать такие функции, как динамические группы или управление правами, чтобы назначить пользователей роли приложения. Если у пользователя есть членство в роли приложения, пользователь сможет получить маркер от Microsoft Entra.
3. Кроме того, AD FS также применяет политики управления доступом, назначенные приложениям. Любая политика, выбранная для приложения, должна оцениваться AD FS как для токенов из Microsoft Entra, так и для пользователей, аутентифицирующихся в AD. Как токены от Microsoft Entra не проходят через Active Directory, вы не можете использовать политику управления доступом Разрешить для определенной группы, так как это будет отклонять токены Microsoft Entra. Если вы хотите управлять доступом в AD FS для выдачи маркеров из AD, вам потребуется использовать другую политику. Дополнительные сведения о политиках управления доступом см. в разделе "Политики управления доступом" в AD FS.

Настройка задачи для автоматической отработки отказа в AD

Затем необходимо настроить монитор для подключения с сайта. Этот монитор вызовет автоматическое переключение поставщика удостоверений для каждого приложения в AD FS от Microsoft Entra к Active Directory при обнаружении отключения, используя команду Set-AdfsRelyingPartyTrust для данного приложения. При желании вы можете настроить монитор для сброса конфигурации AD FS обратно на Microsoft Entra при обнаружении восстановления подключения.

Для простой среды можно реализовать монитор с помощью скрипта PowerShell и встроенного планировщика задач. Для горизонтального развертывания развертывание монитора зависит от системы ит-автоматизации, используемой в вашей организации, и выходит за рамки этой статьи.

Настройка примера запланированной задачи для AD FS

1. Создайте скрипт, который обнаруживает сбой сетевого подключения с сайта и вызывает Set-AdfsRelyingPartyTrust изменение поставщика удостоверений. Пример скрипта можно найти по адресу https://github.com/microsoft/Entra-reporting/blob/main/PowerShell/sample-changeover-multiple-apps.ps1. Обратите внимание, что при скачивании скрипта необходимо использовать проводник для разблокировки скрипта, прежде чем запустить его в PowerShell.
2. Скопируйте скрипт в Windows Server с AD FS.
3. Измените скрипт, чтобы он соответствовал конфигурации AD FS и списку приложений, настроенных в AD FS на этом сайте.
4. Запустите PowerShell на сервере Windows Server, где установлен AD FS.
5. Зарегистрируйте источник, чтобы скрипт смог записать в журнал событий приложения. Например, если скрипт называется AD FS changeover script, введите команду New-EventLog -LogName Application -Source "AD FS changeover script".
6. Запустите средство просмотра событий и перейдите к созданному журналу.
7. Протестируйте скрипт, запустив его в PowerShell, чтобы убедиться, что он работает правильно из интерактивного сеанса.
8. Запустите планировщик задач и просмотрите библиотеку планировщика задач.
9. Если у вас еще нет папки для задач в планировщике задач, создайте папку.
10. Выберите папку для задач, а затем нажмите кнопку "Создать задачу".
11. Заполните параметры вкладки "Общие " для задачи.
12. Перейдите на вкладку "Триггеры ". Выберите "Создать " и укажите расписание повторения для вашей задачи в соответствии с рекомендациями по рискам и сети вашей организации.
13. Перейдите на вкладку "Действия ". Выберите "Создать " и выберите действие для запуска программы. Укажите powershell.exe в качестве программы и укажите аргументы, необходимые для вызова скрипта PowerShell. Например, -NonInteractive -WindowStyle Hidden -File c:\scripts\ad_fs_changeover_script.ps1. Нажмите кнопку "ОК ", чтобы закрыть окно действия и ОК , чтобы закрыть окно задачи. Дополнительные сведения см. в разделе о powershell.exe.
14. Выберите "Выполнить", подождите одну минуту, а затем нажмите кнопку "Обновить". Убедитесь, что скрипт успешно запущен и завершен, и проверьте, были ли записаны ошибки в средстве просмотра событий .

Полная конфигурация

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

Дополнительные сведения о настройке AD FS для обеспечения высокой доступности см. в статье о развертывании фермы серверов федерации.

Дальнейшие действия

• Что такое управление приложениями в идентификаторе Microsoft Entra?
• Управление доступом к приложениям в вашей среде
• Включение единого входа для корпоративного приложения с помощью службы маркеров безопасности проверяющей стороны