Поделиться через

Настройка SQL и устранение проблем с задержкой с AD FS

  • Статья

В обновлении AD FS 2016 мы представили следующие улучшения, чтобы уменьшить задержку между базами данных. В предстоящем обновлении AD FS 2019 будут включены эти улучшения.

Обновление кэша в памяти в фоновом потоке

В предыдущих развертываниях доступности Always on (AoA) задержка существовала для любой операции чтения, так как главный узел может находиться в отдельном центре обработки данных. Вызов между двумя разными центрами обработки данных привел к задержке.

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

backgroundCacheRefreshEnabled Если задано значение true, AD FS позволит фоновому потоку запускать обновления кэша. Частота получения данных из кэша может быть настроена в значение времени, задав параметр cacheRefreshIntervalSecs. Значение по умолчанию равно 300 секундам, если backgroundCacheRefreshEnabled задано значение true. После длительности заданного значения AD FS начинает обновление своего кэша и пока обновление выполняется, старые данные кэша будут продолжать использоваться.

Когда AD FS получает запрос к приложению, AD FS извлекает приложение из SQL и добавляет его в кэш. cacheRefreshIntervalSecs По значению приложение в кэше обновляется с помощью фонового потока. Хотя запись существует в кэше, входящие запросы будут использовать кэш во время выполнения фонового обновления. Если запись недоступна для 5* cacheRefreshIntervalSecs, она удаляется из кэша. После достижения настраиваемого maxRelyingPartyEntries значения можно также удалить старую запись из кэша.

Примечание.

Данные кэша будут обновлены вне cacheRefreshIntervalSecs значения, если AD FS получает уведомление от SQL, указывающее, что в базе данных произошло изменение. Это уведомление активирует обновление кэша.

Рекомендации для настройки обновления кэша

Значение по умолчанию для обновления кэша составляет пять минут. Рекомендуется задать для него значение 1 часа , чтобы уменьшить ненужные обновления данных AD FS, так как данные кэша будут обновляться при возникновении каких-либо изменений SQL.

AD FS регистрирует обратный вызов для изменений SQL и после изменения AD FS получает уведомление. С помощью этого метода AD FS получает каждое новое изменение из SQL сразу после его возникновения.

В случае сбоя сети, в результате чего в AD FS отсутствует уведомление SQL, AD FS будет обновляться в интервале, указанном значением обновления кэша. Если какие-либо проблемы с подключением подозреваются между AD FS и SQL, рекомендуется задать значение обновления кэша меньше 1 часа.

Инструкции по настройке

Файл конфигурации поддерживает несколько записей кэша. Приведенные ниже инструкции можно настроить на основе потребностей вашей организации.

Следующий пример включает обновление фонового кэша и задает период обновления кэша в 1800 секунд или 30 минут. Это необходимо сделать на каждом узле AD FS, а служба AD FS должна быть перезапущена после этого. Изменения не влияют на другие узлы и проверяют первый узел перед внесением изменений во все узлы.

  1. Перейдите к файлу конфигурации AD FS (расположение по умолчанию C:\Windows\ADFS\Microsoft.IdentityServer.ServiceHost.exe.config) и в разделе "Microsoft.IdentityServer.Service" добавьте следующую запись:
  • backgroundCacheRefreshEnabled — указывает, включена ли функция фонового кэша. Значения true/false.
  • cacheRefreshIntervalSecs — Значение в секундах, когда AD FS обновит кэш. AD FS обновит кэш, если в SQL есть какие-либо изменения. AD FS получит уведомление SQL и обновит кэш.

Примечание.

Все записи в файле конфигурации чувствительны к регистру. <cache CacheRefreshIntervalSecs="1800" > backgroundCacheRefreshEnabled="true" />

Дополнительные поддерживаемые настраиваемые значения:

  • maxRelyingPartyEntries — максимальное количество записей проверяющей стороны, которые AD FS будут храниться в памяти. Это значение также используется кэшем разрешений приложения oAuth. Если есть больше разрешений приложения, чем RPs, и если все будет храниться в памяти, это значение должно быть число разрешений приложения. Значение по умолчанию ― 1000.
  • maxIdentityProviderEntries . Это максимальное количество записей поставщика утверждений AD FS будет храниться в памяти. Значение по умолчанию — 200.
  • maxClientEntries — это максимальное количество записей клиента OAuth, которые AD FS будут храниться в памяти. Значение по умолчанию — 500.
  • maxClaimDescriptorEntries — максимальное количество записей дескриптора утверждений AD FS будет храниться в памяти. Значение по умолчанию — 500.
  • maxNullEntries — это используется в качестве отрицательного кэша. Когда AD FS ищет запись в базе данных и не найдена, AD FS добавляется в отрицательный кэш. Это максимальный размер этого кэша. Существует отрицательный кэш для каждого типа объектов, он не является одним кэшем для всех объектов. Значение по умолчанию — 50 0000.

Поддержка нескольких артефактов базы данных в центрах обработки данных

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

Чтобы уменьшить задержку между центрами обработки данных, администратор AD FS теперь может развернуть несколько экземпляров базы данных артефактов, а затем изменить файл конфигурации узла AD FS, чтобы указать на различные экземпляры базы данных артефактов. Базу данных артефактов строка подключения можно указать в файле конфигурации, разрешая базу данных артефактов для каждого узла. Если строка подключения отсутствует в файле конфигурации, узел вернется к предыдущей схеме для использования базы данных артефактов, которая присутствует в базе данных конфигурации. Гибридные среды также поддерживаются с этой конфигурацией.

Требования

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

  1. Создайте скрипт развертывания для создания базы данных артефактов. Чтобы развернуть несколько экземпляров базы данных артефактов, администратору потребуется создать скрипт развертывания SQL для базы данных артефактов. В рамках этого обновления существующий Export-AdfsDeploymentSQLScriptкомандлет был обновлен, чтобы при необходимости принять параметр, указывающий, для какой базы данных AD FS создать скрипт развертывания SQL.

Например, чтобы создать скрипт развертывания только для базы данных артефактов, укажите -DatabaseType параметр и передайте значение Artifact. Необязательный -DatabaseType параметр указывает тип базы данных AD FS и может иметь значение All (default), Artifact или Configuration. Если параметр не -DatabaseType указан, скрипт настраивает скрипты артефакта и конфигурации.

PS C:\> Export-AdfsDeploymentSQLScript -DestinationFolder <script folder where scripts will be created> -ServiceAccountName <domain\serviceaccount> -DatabaseType "Artifact"

Созданный скрипт должен выполняться на компьютере SQL, чтобы создать необходимые базы данных и предоставить учетной записи службы AD FS разрешения SQL SA для этих баз данных.

  1. Создайте базу данных артефактов с помощью скрипта развертывания. Скопируйте недавно созданные CreateDB.sql и SetPermissions.sql скрипты развертывания на компьютер SQL Server и выполните их для создания локальной базы данных Artifact.

  2. Измените файл конфигурации, чтобы добавить подключение к артефактам базы данных. Перейдите к файлу конфигурации узла AD FS и в разделе "Microsoft.IdentityServer.Service" добавьте точку входа в только что настроенную artifactDB.

Примечание.

artifactStore и connectionString — это конфиденциальные значения регистра. Убедитесь, что они настроены правильно. <artifactStore connectionString="Data Source=.\SQLInstance; Встроенная безопасность=True; Initial Catalog=AdfsArtifactStore" />

Используйте значение источника данных, соответствующее подключению sql.

  1. Перезапустите службу AD FS, чтобы изменения вступили в силу.

Примечание.

Не рекомендуется использовать реплика SQL или синхронизацию между базами данных артефактов. Рекомендуется настроить одну базу данных артефактов для каждого центра обработки данных.

Перекрестная отработка отказа центра обработки данных и восстановление базы данных

Рекомендуется создать базы данных артефактов отработки отказа в том же центре обработки данных, что и база данных master artifact. Если происходит отработка отказа, задержка не увеличится. Не рекомендуется использовать базы данных артефактов отработки отказа в центрах обработки данных. Ниже приведены сведения о вызовах функции обнаружения воспроизведения OAuth, SAML, ESL и воспроизведения маркеров с несколькими базами данных артефактов.

  • OAuth и SAML

    Для запросов артефактов OAuth и SAML узел создаст артефакт в базе данных артефактов, присутствующих в файле конфигурации. Если файл конфигурации не содержит подключение к базе данных артефактов, он будет использовать общую базу данных артефактов. Когда следующий запрос на получение артефакта переходит к другому узлу, другой узел сделает rest API на 1-м узле, чтобы получить артефакт из базы данных артефактов. Это необходимо, так как разные узлы могут иметь разные базы данных артефактов, и узлы не знают об этом. Если 1-й узел отключен, разрешение артефакта завершится ошибкой. Из-за этого реплика реплика базы данных артефактов в разных центрах обработки данных не требуется. Если один весь центр обработки данных отключен, скорее всего, узел, который создал артефакт, также вниз, означает, что артефакт больше не может быть разрешен.

  • Блокировка экстрасети

    База данных Artifact, на которую ссылается файл конфигурации, будет использоваться для данных блокировки экстрасети. Однако для функции ESL AD FS выбирает главный объект, который записывает данные в базу данных артефактов. Все узлы вызывают REST API к главному узлу, чтобы получить и задать последние сведения о каждом пользователе. Если используются несколько баз данных артефактов, администратор должен выбрать главный узел для каждого артефакта базы данных или центра обработки данных.

    Чтобы выбрать один узел для ESL master, перейдите к файлу конфигурации узла AD FS и в разделе "Microsoft.IdentityServer.Service" добавьте следующее:

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

    <useractivityfarmrole masterFQDN=[полное доменное имя выбранного первичного] isMaster="true"/>

    На других узлах добавьте следующую запись:

    <useractivityfarmrole masterFQDN=[полное доменное имя выбранного первичного] isMaster="false"/>

    Примечание.

    Так как несколько баз данных артефактов не синхронизируют данные, значения ESL не будут синхронизированы между DOB-объектами артефактов. Возможно, пользователь может попасть в другой центр обработки данных для запроса, поэтому это означает, что экстрасетьLockoutThreshold зависит от количества DOB-объектов артефактов, экстрасетиLockoutThreshold * Число DOB-объектов артефакта.

    • Обнаружение воспроизведения маркеров

      Данные обнаружения воспроизведения маркеров всегда вызываются из центральной базы данных Artifact. AD FS сохраняет маркер из доверия поставщика утверждений, гарантируя, что тот же маркер не может быть воспроизведен. Если злоумышленник пытается воспроизвести тот же токен, AD FS проверяет, существует ли маркер в базе данных артефактов. Если маркер присутствует, запрос будет отклонен. Центральная база данных Артефакта используется для обеспечения безопасности, так как данные базы данных Artifact не реплика ted, злоумышленник может отправить запрос в другой центр обработки данных и воспроизвести маркер. Создание дополнительных копий artifactDB не будет препятствовать задержке между центрами обработки данных в этом сценарии, так как используется только центральная база данных Artifact.