Новые возможности служб федерации Active Directory

  • Статья

Новые возможности служб федерации Active Directory для Windows Server 2019

В этой статье описываются новые изменения, внесенные в службы федерации Active Directory (AD FS) (AD FS).

Защищенные входы

Ниже приведены краткие сведения об обновлениях защищенных входов, доступных в службы федерации Active Directory (AD FS) (AD FS) 2019:

  • Внешние поставщики проверки подлинности в качестве основного. Теперь клиенты могут использовать сторонние продукты проверки подлинности в качестве первого фактора и не предоставлять пароли в качестве первого фактора. В случаях, когда внешний поставщик проверки подлинности может доказать два фактора, он может претендовать на MFA.
  • Проверка подлинности паролей в качестве дополнительной проверки подлинности. Клиенты имеют полностью поддерживаемый встроенный параметр, чтобы использовать пароли только в качестве дополнительного фактора после того, как параметр без пароля используется в качестве первого фактора. Этот параметр улучшает взаимодействие с клиентами из AD FS 2016, где клиентам пришлось скачать адаптер GitHub, поддерживаемый как есть.
  • Подключаемый модуль оценки рисков. Теперь клиенты могут создавать собственные модули подключаемых модулей для блокировки определенных типов запросов на этапе предварительной проверки подлинности. Эта функция упрощает использование облачных аналитики, таких как защита идентификации для блокировки входа для рискованных пользователей или рискованных транзакций. Дополнительные сведения см. в статье о подключаемых модулях сборки с помощью модели оценки рисков AD FS 2019.
  • Улучшения ESL. Улучшена инженерия быстрого исправления ESL (QFE) в 2016 году, добавив следующие возможности:
    • Позволяет клиентам находиться в режиме аудита при защите с помощью функции блокировки классической экстрасети, доступной с AD FS 2012R2. Клиенты версии 2016 сейчас не могут использовать защиту в режиме аудита.
    • Применение независимого порога блокировки для знакомых расположений. Эта функция позволяет использовать несколько экземпляров приложений, работающих с общей учетной записью службы, для переката паролей с минимальным количеством эффектов.

Другие улучшения безопасности

В AD FS 2019 доступны следующие улучшения безопасности:

  • Удаленное подключение PowerShell с помощью входа в SmartCard. Теперь клиенты могут использовать смарт-карты для удаленного подключения к AD FS с помощью PowerShell и использовать их для управления всеми функциями PowerShell, включая командлеты с несколькими узлами.
  • Настройка заголовка HTTP. Теперь клиенты могут настраивать заголовки HTTP, созданные во время ответов AD FS, включая следующие заголовки:
    • HSTS: этот заголовок передает, что конечные точки AD FS можно использовать только в конечных точках HTTPS для принудительного применения браузера.
    • X-frame-options: позволяет администраторам AD FS разрешить определенным проверяющим сторонам внедрять iFrames для страниц интерактивного входа AD FS. Этот заголовок следует использовать с осторожностью и только на узлах HTTPS.
    • Будущий заголовок: можно также настроить другие будущие заголовки.

Дополнительные сведения см. в разделе "Настройка заголовков ответов безопасности HTTP с помощью AD FS 2019".

Возможности проверки подлинности и политики

В AD FS 2019 доступны следующие возможности проверки подлинности и политики:

  • Укажите метод проверки подлинности для другого метода проверки подлинности на RP. Теперь клиенты могут использовать правила утверждений, чтобы решить, какой другой поставщик проверки подлинности будет вызываться для дополнительной проверки подлинности. Эта функция полезна для двух вариантов использования:
    • Клиенты переходят с одного другого поставщика проверки подлинности на другой. Таким образом, при подключении пользователей к новому поставщику проверки подлинности они могут использовать группы для управления вызовом дополнительного поставщика проверки подлинности.
    • У клиентов есть требования к конкретному дополнительному поставщику проверки подлинности (например, сертификату) для определенных приложений.
  • Ограничить проверку подлинности устройства на основе TLS только приложениям, которым это требуется. Теперь клиенты могут ограничить проверку подлинности устройства на основе ПРОТОКОЛА TLS только приложениям, выполняющим условный доступ на основе устройств. Этот параметр предотвращает любые нежелательные запросы на проверку подлинности устройства (или сбои, если клиентское приложение не может обрабатывать) для приложений, которые не требуют проверки подлинности на основе TLS.
  • Поддержка свежести многофакторной проверки подлинности (MFA). AD FS теперь поддерживает возможность повторного ввода учетных данных второго фактора на основе свежести учетных данных второго фактора. Эта функция позволяет клиентам выполнять начальную транзакцию с двумя факторами и периодически запрашивать второй фактор. Эта функция доступна только для приложений, которые могут предоставить дополнительный параметр в запросе и не является настраиваемым параметром в AD FS. Azure AD поддерживает этот параметр при настройке "Запомнить MFA в течение X дней" и задать для флага "поддержкаMFA" значение true в параметрах доверия федеративного домена Azure AD.

Улучшения единого входа

В AD FS 2019 были улучшены следующие улучшения единого входа:

  • Интерфейс с разбивкой на страницы с центрированной темой. AD FS теперь перемещен в поток пользовательского интерфейса с разбивкой на страницы, который позволяет AD FS проверять и обеспечивать более плавный вход. AD FS теперь использует пользовательский интерфейс с выравниванием по центру (вместо выравнивания по правой стороне экрана). Для соответствия этому интерфейсу может потребоваться более новые логотипы и фоновые изображения. Это изменение также зеркало функциональные возможности, предлагаемые в Azure AD.
  • Исправлена ошибка: постоянное состояние единого входа для устройств Win10 при выполнении проверки подлинности первичного маркера обновления (PRT). Это изменение устраняет проблему, из-за которой состояние MFA не сохранялось при использовании проверки подлинности PRT для устройств Windows 10. Результатом проблемы было то, что конечные пользователи будут часто запрашивать учетные данные второго фактора (MFA). Кроме того, это исправление улучшит взаимодействие в сценариях, когда аутентификация устройства успешно выполнена через клиент TLS и механизм PRT.

Поддержка создания современных бизнес-приложений

В AD FS 2019 добавлена следующая поддержка создания современных бизнес-бизнес-приложений:

  • Поток или профиль устройства Oauth. AD FS теперь поддерживает профиль потока устройств OAuth для входа на устройства, у которых нет области пользовательского интерфейса для поддержки расширенных возможностей входа. Эта функция позволяет пользователю выполнять вход на другом устройстве. Эта функция необходима для интерфейса командной строки Azure в Azure Stack и может использоваться в других случаях.
  • Удаление параметра Resource. AD FS теперь удалил требование указать параметр ресурса, который соответствует текущим спецификациям Oauth. Теперь клиенты могут предоставить идентификатор доверия проверяющей стороны в качестве параметра область в дополнение к запрошенным разрешениям.
  • Заголовки общего доступа к ресурсам (CORS) между источниками в ответах AD FS. Теперь клиенты могут создавать одностраничные приложения, которые позволяют клиентским библиотекам JavaScript проверять подпись id_token, запрашивая ключи подписи из документа обнаружения OpenID Подключение (OIDC) в AD FS.
  • Поддержка проверки ключа для обмена кодом (PKCE). AD FS добавляет поддержку PKCE для обеспечения безопасного потока кода проверки подлинности в OAuth. Эта функция добавляет дополнительный уровень безопасности в этот поток, чтобы предотвратить перехват кода и повторение его от другого клиента.
  • Исправление ошибки: отправка утверждения x5t и ребенка. Это изменение является незначительным исправлением ошибок. AD FS теперь дополнительно отправляет утверждение "kid", чтобы указать подсказку идентификатора ключа для проверки подписи. Ранее AD FS отправил только утверждение x5t.

Расширения поддержки

Следующие улучшения поддержки теперь являются частью AD FS 2019:

  • Отправка сведений об ошибке администраторам AD FS. Позволяет администраторам настраивать конечных пользователей отправлять журналы отладки, связанные с сбоем при проверке подлинности конечных пользователей, которые будут храниться в виде zip-файла, отправленного для простого использования. Администратор также может настроить подключение simple Mail Transfer Protocol (SMTP) для автоматической отправки zippped-файла в учетную запись электронной почты или автоматически создать билет на основе сообщения электронной почты.

Обновления для развертывания

В AD FS 2019 теперь включены следующие обновления для развертывания.

  • Уровень поведения фермы 2019. Как и в AD FS 2016, существует новая версия уровня поведения фермы, которая необходима для включения новых функций, рассмотренных далее в статье. Это обновление позволяет выполнять следующие действия:
    • AD FS в Windows Server 2012 R2 в AD FS в Windows Server 2016.
    • AD FS в Windows Server 2016 в AD FS в Windows Server 2019.

Обновления SAML

Следующее обновление языка разметки утверждения безопасности (SAML) находится в AD FS 2019:

  • Исправление ошибок: исправление ошибок в агрегированной федерации. Существует множество исправлений ошибок вокруг агрегированной поддержки федерации (например, InCommon). Следующие области получили исправления:
    • Улучшено масштабирование для большого количества сущностей в документации по агрегированным метаданным федерации. Ранее масштабирование завершилось ошибкой "ADMIN0017".
    • Запрос с помощью параметра ScopeGroupID с помощью Get-AdfsRelyingPartyTrustsGroup командлета PowerShell.
    • Обработка условий ошибок вокруг дубликата entityID.

Спецификация ресурсов в стиле Azure AD для параметра scope.

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

https://fs.contoso.com/adfs/oauth2/authorize?response_type=code&client_id=claimsxrayclient&resource=urn:microsoft:adfs:claimsxray&scope=oauth&redirect_uri=https://adfshelp.microsoft.com/
ClaimsXray/TokenResponse&prompt=login

С обновлением AD FS в Server 2019 вы сможете передать значение ресурса, внедренное в параметр scope. Это изменение соответствует тому, как можно также выполнить проверку подлинности в Azure AD.

Параметр scope теперь можно упорядочить в виде списка с разделителями-пробелами, где каждая запись представляет собой структуру из ресурса и области.

Примечание.

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

Поддержка протокола PKCE (ключ подтверждения для обмена кодами) в OAuth

Общедоступные клиенты OAuth, которые используют предоставление кода авторизации, уязвимы для атаки методом перехвата кода авторизации. Эта атака хорошо описана в документе RFC 7636. Чтобы устранить эту опасность, AD FS в Server 2019 поддерживает PKCE (ключ подтверждения для обмена кодами) для потока предоставления кода авторизации OAuth.

Чтобы использовать поддержку PKCE, эта спецификация добавляет дополнительные параметры в запросы на авторизацию OAuth 2.0 и маркер доступа.

Diagram of the PKCE relationship between the client and AD FS 2019.

A. Клиент создает и записывает секрет с именем "code_verifier" и получает преобразованную версию "t(code_verifier)" (называемую "code_challenge"). Секрет отправляется в запросе авторизации OAuth 2.0 вместе с методом преобразования "t_m".

B. Конечная точка авторизации реагирует как обычно, но записывает "t(code_verifier)" и метод преобразования.

C. Затем клиент отправляет код авторизации в запросе маркера доступа как обычно, но включает секрет code_verifier, созданный по адресу (A).

D. AD FS преобразует code_verifier и сравнивает его с t(code_verifier) из шага (B). Доступ запрещен, если они не равны.

Выбор дополнительных поставщиков проверки подлинности в 2019 году

AD FS уже поддерживает активацию дополнительной проверки подлинности на основе политики правила утверждений. Эти политики можно задать для определенной проверяющей стороны или на глобальном уровне. Вы можете задать дополнительную политику проверки подлинности для определенной RP с помощью командлета Set-AdfsRelyingPartyTrust (AD FS) | Документация Майкрософт путем передачи параметра AdditionalAuthenticationRules или AdditionalAuthenticationRulesFile. Чтобы задать его глобально, администратор может использовать командлет Set-AdfsAdditionalAuthenticationRule (AD FS) | Документация Майкрософт.

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

Set-AdfsAdditionalAuthenticationRule -AdditionalAuthenticationRules 'c:[type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = "https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = "https://schemas.microsoft.com/claims/multipleauthn" );'

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

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

У клиентов есть потребность в конкретном дополнительном поставщике проверки подлинности (например, сертификате) для определенных приложений, но для других приложений используется другой метод (Многофакторная идентификация Azure AD).

Эта конфигурация может быть достигнута путем выдачи утверждения https://schemas.microsoft.com/claims/authnmethodsproviders из других политик проверки подлинности. Значение этого утверждения должно быть именем поставщика аутентификации.

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

Переход с одного другого поставщика проверки подлинности на другой: можно изменить ранее упоминание правило, чтобы выбрать Многофакторную проверку подлинности Azure AD для пользователей, которые находятся в группе SID S-1-5-21-608905689-872870963-3921916988-12345. Например, это изменение можно использовать для группы, управляемой корпорацией, которая отслеживает пользователей, зарегистрированных для Многофакторной идентификации Azure AD. Это изменение также работает для остальных пользователей, которым администратор хочет использовать проверку подлинности сертификатов.

'c:[type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "https://schemas.microsoft.com/claims/multipleauthn" ); 

 c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-608905689-872870963-3921916988-12345"] => issue(Type = "`https://schemas.microsoft.com/claims/authnmethodsproviders`", Value = "AzureMfaAuthentication"); 

not exists([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value=="S-1-5-21-608905689-872870963-3921916988-12345"]) => issue(Type = "`https://schemas.microsoft.com/claims/authnmethodsproviders`", Value = "CertificateAuthentication");’

В этом примере показано, как задать два разных поставщика проверки подлинности для двух разных приложений:

Задайте приложению A использование Многофакторной идентификации Azure AD в качестве дополнительного поставщика проверки подлинности:

Set-AdfsRelyingPartyTrust -TargetName AppA -AdditionalAuthenticationRules 'c:[type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "https://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication");'

Задайте приложению B использование сертификата в качестве дополнительного поставщика проверки подлинности:

Set-AdfsRelyingPartyTrust -TargetName AppB -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");'

Администратор также могут создавать правила для разрешения нескольких дополнительных поставщиков проверки подлинности. В этом случае AD FS отображает выданные поставщики методов проверки подлинности, и пользователь может выбрать любой из них. Чтобы разрешить несколько дополнительных поставщиков проверки подлинности, они должны выдавать несколько утверждений https://schemas.microsoft.com/claims/authnmethodsproviders.

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

Чтобы получить все остальные поставщики проверки подлинности, администратор может использовать командлет (Get-AdfsGlobalAuthenticationPolicy). AdditionalAuthenticationProvider. Значение https://schemas.microsoft.com/claims/authnmethodsproviders утверждения должно быть одним из имен поставщика, возвращаемых ранее упоминание командлетом.

Нет поддержки активации определенного дополнительного поставщика проверки подлинности, если RP использует политики контроль доступа в AD FS Windows Server 2016 | Документация Майкрософт. При перемещении приложения из политики управления доступом AD FS копирует соответствующую политику из политики контроль доступа в AdditionalAuthenticationRules и IssuanceAuthorizationRules. Таким образом, если администратор хочет использовать конкретный поставщик проверки подлинности, он может уйти от использования политики управления доступом, а затем изменить Параметр AdditionalAuthenticationRules, чтобы активировать конкретный поставщик проверки подлинности.

Вопросы и ответы

Разделы справки устранить ошибку журналов событий AD FS Администратор "Получено недопустимое запрос Oauth. Клиенту "NAME" запрещен доступ к ресурсу с область "ugs".

Выполните следующие действия, чтобы устранить проблему:

  1. Запустите консоль управления AD FS. Перейдите к описаниям областей служб>.
  2. Выберите дополнительные параметры в разделе "Описания области" и выберите "Добавить описание области".
  3. Под именем введите "ugs" и нажмите кнопку "Применить>".
  4. Запустите PowerShell как Администратор istrator.
  5. Выполните команду Get-AdfsApplicationPermission. Найдите тот ScopeNames :{openid, aza} , который имеет ClientRoleIdentifier. Запишите ObjectIdentifier.
  6. Выполните команду Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs'.
  7. Перезагрузите службу AD FS.
  8. На клиенте перезапустите клиент. Вам потребуется настроить Windows Hello для бизнеса (WHFB).
  9. Если окно конфигурации не появится, необходимо собирать журналы трассировки и устранять неполадки.

Можно ли передать значение ресурса как часть значения область, например, как запросы выполняются в Azure AD?

С обновлением AD FS в Server 2019 вы сможете передать значение ресурса, внедренное в параметр scope. Параметр scope теперь можно упорядочить в виде списка с разделителями-пробелами, где каждая запись представляет собой структуру из ресурса и области. Например: <create a valid sample request>

Поддерживает ли AD FS расширение PKCE?

AD FS в Server 2019 поддерживает ключ проверки для кода Exchange (PKCE) для потока предоставления кода авторизации OAuth.

Новые возможности службы федерации Active Directory (AD FS) для Windows Server 2016

Если вы ищете информацию о более ранних версиях AD FS, ознакомьтесь со следующими статьями: AD FS в Windows Server 2012 или 2012 R2 и AD FS 2.0.

AD FS обеспечивает управление доступом и единый вход в различных приложениях, включая Office 365, облачные приложения SaaS и приложения в корпоративной сети.

  • Для ИТ-организации вы можете обеспечить вход и управление доступом как к современным, так и устаревшим приложениям на любом компьютере на основе одного набора учетных данных и политик.
  • Для пользователя он предоставляет простой вход с использованием одинаковых знакомых учетных данных учетной записи.
  • Разработчики смогут легко выполнять проверку подлинности для пользователей, удостоверения которых размещены в каталоге организации. Это позволяет сосредоточиться на основных функциях приложения, не отвлекаясь на организацию проверки подлинности или управления удостоверениями.

Устранение паролей из экстрасети

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

Вход с помощью многофакторной проверки подлинности Azure Active Directory

AD FS 2016 основывается на возможностях многофакторной проверки подлинности (MFA) AD FS в Windows Server 2012 R2. Теперь вы можете разрешить вход только с помощью кода Многофакторной идентификации Azure AD, не вводя имя пользователя и пароль.

  • При использовании Многофакторной идентификации Azure AD в качестве основного метода проверки подлинности пользователь запрашивает имя пользователя и код OTP из приложения Azure Authenticator.
  • При использовании Многофакторной идентификации Azure AD в качестве дополнительного или дополнительного метода проверки подлинности пользователь предоставляет первичные учетные данные проверки подлинности. Они могут выполнять вход с помощью встроенной проверки подлинности Windows с помощью имени пользователя и пароля, смарт-карта или сертификата пользователя или устройства. Затем они видят запрос на вход в Систему Многофакторной идентификации Azure AD на основе текста, голоса или OTP.
  • Благодаря новому встроенному адаптеру Многофакторной идентификации Azure AD настройка и настройка многофакторной идентификации Azure AD с ad FS никогда не была проще.
  • Организации могут воспользоваться преимуществами Многофакторной идентификации Azure AD без необходимости локального сервера Многофакторной идентификации Azure AD.
  • Многофакторная проверка подлинности Azure AD может быть настроена для интрасети или экстрасети или в рамках любой политики управления доступом.

Дополнительные сведения о Многофакторной идентификации Azure AD с помощью AD FS см. в статье "Настройка многофакторной идентификации AD FS 2016 и Многофакторной идентификации Azure AD".

Доступ без пароля с совместимых устройств

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

  • Включите доступ только с устройств, управляемых и /или совместимых.
  • Включите доступ экстрасети только с устройств, управляемых и /или совместимых.
  • Требовать многофакторную проверку подлинности для компьютеров, которые не управляются или не соответствуют требованиям.

AD FS реализует локальный компонент политик условного доступа в гибридном сценарии. Если вы зарегистрируете устройство в Azure AD для условного доступа к облачным ресурсам, удостоверение этого устройства можно будет использовать и для политик AD FS.

Diagram of a hybrid solution and the relationships between users and on-premises active directory.

Дополнительные сведения об использовании условного доступа на основе устройств в облаке см. в статье об условном доступе Azure Active Directory.

Дополнительные сведения об использовании условного доступа на основе устройств в AD FS:

Вход с помощью Windows Hello для бизнеса

Примечание.

В настоящее время Google Chrome и новые браузеры проектов Microsoft Edge, созданные на основе Chromium открытый код, не поддерживаются для единого входа в браузер с Windows Hello для бизнеса. Используйте Internet Explorer или более старую версию Microsoft Edge.

На устройствах Windows 10 применяются Windows Hello и Windows Hello для бизнеса. Они заменяют пароли пользователей строгими учетными данными пользователей, защищенными жестами пользователя (ПИН-код, отпечаток пальца или другой биометрический жест, распознавание лиц). AD FS 2016 поддерживает эти новые возможности Windows 10, чтобы пользователи могли входить в приложения AD FS из интрасети или экстрасети без предоставления пароля.

Дополнительные сведения об использовании Windows Hello для бизнеса в организации см. в разделе "Включение Windows Hello для бизнеса в организации".

Безопасный доступ к приложениям.

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

Современная аутентификация

AD FS 2016 поддерживает новейшие современные протоколы, которые обеспечивают лучший пользовательский интерфейс для Windows 10 и последних устройств и приложений iOS и Android.

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

Настройка политик управления доступом без изучения языка правил утверждений

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

  • Разрешить доступ к интрасети только.
  • Разрешить всем пользователям и требовать многофакторную проверку подлинности из Экстрасети.
  • Разрешить всем пользователям и требовать многофакторную проверку подлинности из определенной группы.

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

Дополнительные сведения см. в политиках управления доступом в AD FS.

Вход через каталоги LDAP, не поддерживающие AD

Многие организации используют одновременно Active Directory и сторонние каталоги. Благодаря добавлению поддержки AD FS для проверки подлинности пользователей, хранящихся в каталогах, совместимых с протоколом LDAP версии 3, ad FS теперь можно использовать для:

  • Пользователи сторонних поставщиков, каталоги, совместимые с LDAP версии 3.
  • Пользователи в лесах Active Directory, к которым не настроено двустороннее доверие Active Directory.
  • Пользователи в службах упрощенного каталога Active Directory (AD LDS).

Дополнительные сведения см. в разделе Configure AD FS to authenticate users stored in LDAP directories.

Улучшенный интерфейс входа

В следующих изменениях улучшен интерфейс входа для AD FS.

Настройка интерфейса входа для приложений AD FS

Ранее AD FS в Windows Server 2012 R2 предоставлял общий интерфейс входа для всех приложений проверяющей стороны с возможностью настройки подмножества содержимого на основе текста для каждого приложения. Начиная с Windows Server 2016, вы можете настраивать не только сообщения, но и изображения, эмблемы, а также веб-темы отдельно для каждого приложения. Кроме того, вы можете создавать новые, пользовательские веб-темы и применять эти темы на проверяющую сторону.

Дополнительные сведения см. в разделе о настройке входа пользователей AD FS.

Усовершенствования управления и эксплуатации

В следующем разделе описаны усовершенствования в службах федерации Active Directory (AD FS) в Windows Server 2016, затронувшие сценарии эксплуатации.

Упрощенный аудит для облегчения административного управления

В AD FS для Windows Server 2012 R2 были многочисленные события аудита, созданные для одного запроса, и соответствующие сведения о действии выдачи маркеров либо отсутствуют, либо распределены по нескольким событиям аудита. По умолчанию события аудита AD FS отключены, так как они создают большой объем информации. В выпуске AD FS 2016 аудит стал более простым и менее подробным.

Дополнительные сведения см. в статье об усовершенствованиях аудита AD FS в Windows Server 2016.

Улучшение взаимодействия с SAML 2.0 для участия в конфедерациях

AD FS 2016 содержит больше поддержки протокола SAML, включая поддержку импорта доверия на основе метаданных, содержащих несколько сущностей. Это изменение позволяет настроить AD FS для участия в конфедерациях, таких как Федерация InCommon и другие реализации, соответствующие стандарту eGov 2.0.

Дополнительные сведения см. в разделе "Улучшенная совместимость с SAML 2.0".

Упрощенное управление паролями для федеративных пользователей Microsoft 365

Вы можете настроить в службах федерации Active Directory (AD FS) отправку утверждений об истечении срока действия пароля проверяющим сторонам (приложениям), которые защищены в AD FS. Приложение самостоятельно решит, как использовать эти утверждения. Например, если проверяющая сторона — Office 365, в Exchange и Outlook реализованы обновления для уведомления федеративных пользователей о скором истечении срока действия пароля.

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

Переход с AD FS в Windows Server 2012 R2 на AD FS в Windows Server 2016 стал проще

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

Теперь переход с AD FS в Windows Server 2012 R2 на AD FS в Windows Server 2016 стал проще. Добавьте новый сервер Windows Server 2016 в ферму Windows Server 2012 R2, а ферма действует на уровне поведения фермы Windows Server 2012 R2. Теперь сервер выглядит и ведет себя так же, как ферма Windows Server 2012 R2.

Затем добавьте в ферму все новые серверы Windows Server 2016, проверьте их работоспособность и удалите старые серверы из подсистемы балансировки нагрузки. После запуска всех узлов фермы Windows Server 2016 вы готовы обновить уровень поведения фермы до 2016 года и начать работу с новыми функциями.

Дополнительные сведения см. в разделе "Обновление до AD FS" в Windows Server 2016.