Рекомендации по защите служб федерации active directory

Рекомендуемые конфигурации безопасности

Убедитесь, что все AD FS и WAP-серверы получают самые актуальные обновления

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

для клиентов Azure AD рекомендуется отслеживать и отслеживать текущую инфраструктуру с помощью Azure AD Connect Health для AD FS, функции Azure AD Premium. Azure AD Connect Health включает мониторы и оповещения, которые инициируются, если на компьютере AD FS или wap отсутствует одно из важных обновлений, специально предназначенное для AD FS и WAP.

сведения об установке Azure AD Connect Health для AD FS можно найти здесь.

Настройка служб федерации Active Directory (AD FS)

Вам необходимо настроить AD FS на сервере Windows 2016 в вашей среде. Для этой настройки, в диспетчере серверов в разделе «Управление» выберите «Добавить роли и компоненты». Дополнительные сведения см. в документации служб федерации Active Directory.

На сервере AD FS с помощью приложения управления AD FS выполните следующие действия.

1. Щелкните правой кнопкой мыши отношения доверия проверяющейстороны Добавить отношение доверияс проверяющей стороной.

2. Выполните действия, описанные в мастере добавления отношения доверия проверяющей стороны.

   Выберите параметр Не поддерживающие утверждения, чтобы использовать встроенную систему безопасности Windows в качестве механизма проверки подлинности.

   Введите нужное имя в поле Укажите отображаемое имя и выберите команду Далее.
   Добавьте идентификатор отношения доверия проверяющей стороны:

   Пример:

   Выберите политику управления доступом, которая соответствует требованиям вашей организации, а затем нажмите кнопку Далее.

   Нажмите кнопку Далее, а затем выберите команду Завершить, чтобы завершить работу мастера добавления отношений доверия проверяющей стороны.

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

Template for deploying AD FS in Azure

The template deploys a 6 machine setup, 2 each for Domain Controllers, AD FS and WAP.

You can use an existing virtual network or create a new VNET while deploying this template. The various parameters available for customizing the deployment are listed below with the description of usage of the parameter in the deployment process.

Parameter	Description
Location	The region to deploy the resources into, e.g. East US.
StorageAccountType	The type of the Storage Account created
VirtualNetworkUsage	Indicates if a new virtual network will be created or use an existing one
VirtualNetworkName	The name of the Virtual Network to Create, mandatory on both existing or new virtual network usage
VirtualNetworkResourceGroupName	Specifies the name of the resource group where the existing virtual network resides. When using an existing virtual network, this becomes a mandatory parameter so the deployment can find the ID of the existing virtual network
VirtualNetworkAddressRange	The address range of the new VNET, mandatory if creating a new virtual network
InternalSubnetName	The name of the internal subnet, mandatory on both virtual network usage options (new or existing)
InternalSubnetAddressRange	The address range of the internal subnet, which contains the Domain Controllers and AD FS servers, mandatory if creating a new virtual network.
DMZSubnetAddressRange	The address range of the dmz subnet, which contains the Windows application proxy servers, mandatory if creating a new virtual network.
DMZSubnetName	The name of the internal subnet, mandatory on both virtual network usage options (new or existing).
ADDC01NICIPAddress	The internal IP address of the first Domain Controller, this IP address will be statically assigned to the DC and must be a valid ip address within the Internal subnet
ADDC02NICIPAddress	The internal IP address of the second Domain Controller, this IP address will be statically assigned to the DC and must be a valid ip address within the Internal subnet
ADFS01NICIPAddress	The internal IP address of the first AD FS server, this IP address will be statically assigned to the AD FS server and must be a valid ip address within the Internal subnet
ADFS02NICIPAddress	The internal IP address of the second AD FS server, this IP address will be statically assigned to the AD FS server and must be a valid ip address within the Internal subnet
WAP01NICIPAddress	The internal IP address of the first WAP server, this IP address will be statically assigned to the WAP server and must be a valid ip address within the DMZ subnet
WAP02NICIPAddress	The internal IP address of the second WAP server, this IP address will be statically assigned to the WAP server and must be a valid ip address within the DMZ subnet
ADFSLoadBalancerPrivateIPAddress	The internal IP address of the AD FS load balancer, this IP address will be statically assigned to the load balancer and must be a valid ip address within the Internal subnet
ADDCVMNamePrefix	Virtual Machine name prefix for Domain Controllers
ADFSVMNamePrefix	Virtual Machine name prefix for AD FS servers
WAPVMNamePrefix	Virtual Machine name prefix for WAP servers
ADDCVMSize	The virtual machine size of the Domain Controllers
ADFSVMSize	The virtual machine size of the AD FS servers
WAPVMSize	The virtual machine size of the WAP servers
AdminUserName	The name of the local Administrator of the virtual machines
AdminPassword	The password for the local Administrator account of the virtual machines

Мультидоменность

ВНИМАНИЕ!

Использование зарезервированных символов XML в конфигурационном файле запрещено (& «<‘>).

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

Мультидоменность работает по протоколу NTLM.

Настройки на сервере IIS

1. Для авторизации на сервере через AD необходимо установить службу «Windows – проверка подлинности» ().

Windows Server 2008 R2:

1. Открыть диспетчер сервера.
2. Перейти в пункт «Роли».
3. На вкладке «Службы ролей» нажать на кнопку «Добавить службы ролей».
4. В пункте «Безопасность» включить пункт «Windows — проверка подлинности».
5. Нажать «Далее».
6. «Установить».

Windows Server 2012:

1. Открыть диспетчер серверов.
2. «Управление» → «Добавить роли и компоненты».
3. На шаге «Перед началом работы» нажать «Далее».
4. На шаге «Тип установки» выбрать «Установка ролей или компонентов» и нажать «Далее».
5. На шаге «Выбор сервера» выбрать текущий сервер.
6. Перейти в пункт «Роль веб-сервера(IIS)» → «Службы ролей».
7. В пункте «Безопасность» включить пункт «проверка подлинности Windows».
8. Нажать «Далее», затем «Установить».

После установки службы «Windows — проверка подлинности» откройте Диспетчер служб IIS:

1. Перейти в раздел «Сайты» → Default Web Site (сайт с установленной системой).
2. Затем перейти в подраздел «Проверка подлинности» (в области просмотра возможностей).
3. Включить компонент «Проверка подлинности Windows».
4. Включить компонент «Анонимная проверка подлинности».
5. Все остальные компоненты выключить, если они включены.

2. Настройка client.config:

• добавляем теги в :

  <section name="ldapService" type="Config.LDAPConfigurationSection, smcorelib"/>
  <section name="adDomains" type="Config.ADDomainsConfiguration, smcorelib"/>

• добавляем тег в корень после тега :

  <adDomains>
    <domains>
      <add name="Имя домена" login="Логин пользователя" password="Пароль" ldappath="LDAP://Адрес LDAP(127.0.0.1:389)" />
    </domains>
  </adDomains>

где:

• значение «Имя домена» – любое понятное имя домена, которое будет использоваться в дереве при загрузке пользователей из каталога;
• значение «Логин пользователя» – логин любого пользователя того домена, от куда будет производиться загрузка пользователей;
• значение «Пароль» – пароль пользователя, логин которого использовался в значении «Логин пользователя» (выше);
• значение «LDAP://Адрес LDAP» – адрес службы LDAP (например: или ).

Для добавления нескольких доменов нужно добавить соответствующее количество строк, начинающихся с тега «add name…».

Настройка рабочих станций

Добавить систему в раздел Местная интрасеть (Свойства браузера → Безопасность → Местная интрасеть → Сайты → Добавить сайт с адресом системы → Закрыть).

Управление настройкой закрытого ключа

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

1. Нажмите кнопку Пуск, затем щелкните Выполнить.

2. Введите MMC.

3. В меню Файл выберите Добавить или удалить оснастку.

4. В списке Доступные оснастки выберите пункт Сертификаты и нажмите кнопку Добавить. Запустится мастер оснастки сертификатов.

   

   

   

   

   

   

   

   

   

   

5. Выберите Учетная запись компьютера и нажмите кнопку Далее.

6. Выберите Локальный компьютер: (компьютер, на котором запущена эта консоль) и нажмите кнопку Готово.

7. Нажмите кнопку ОК.

8. Разверните папку Console рут\цертификатес (локальный компьютер) \персонал\цертификатес.

9. Щелкните правой кнопкой мыши Сертификат AD FS, нажмите Все задачи, а затем — Управление закрытыми ключами.

10. В окне Разрешения нажмите Добавить.

11. В окне Типы объектов выберите Учетные записи служб и нажмите кнопку ОК.

12. Введите имя учетной записи, под которой выполняется AD FS. В тестовом примере используется имя ADFSService. Нажмите кнопку ОК.

13. В окне Разрешения предоставьте учетной записи хотя бы разрешения на чтение и нажмите кнопку ОК.

Если у вас нет возможности управлять закрытыми ключами, может потребоваться выполнить следующую команду:

Развертывание роли службы федерации Active Directory (AD FS)

Роль службы федерации Active Directory (AD FS) предоставляет следующие службы для поддержки локальных развертываний Windows Hello для бизнеса.

• Регистрация устройств
• Регистрация ключей

Важно!

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

Для Windows Hello для бизнеса необходима правильная регистрация устройств. Для локальных развертываний Windows Server 2016 с доверием на основе ключей AD FS обрабатывает регистрацию устройств и ключей.

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

1. Запустите Диспетчер серверов. В области навигации щелкните Локальный сервер.
2. Щелкните Управление, а затем нажмите кнопку Добавить роли и компоненты.
3. На странице Перед работой нажмите кнопку Далее.
4. На странице Выбор типа установки выберите параметр Установка ролей или компонентов и нажмите кнопку Далее.
5. На странице Выбор целевого сервера выберите Выберите сервер из пула серверов. Выберите сервер федерации из списка Пул серверов. Нажмите кнопку Далее.
6. На странице Выбор ролей сервера выберите Службы федерации Active Directory (AD FS). Нажмите кнопку Далее.
7. Нажмите кнопку Далее на странице Выбор компонентов.
8. На странице Служба федерации Active Directory (AD FS) нажмите кнопку Далее.
9. Нажмите кнопку Установить, чтобы начать установку роли.

Разработчик

Значение утверждения sub — это хэш идентификатора клиента и значение утверждения привязки.

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

Вы можете использовать настроенный маркер id_token для добавления нужной информации в сам id_token. Дополнительную информацию см. в статье Настройка утверждений, которые будут генерироваться в id_token при использовании OpenID Connect или OAuth с AD FS 2016 или более поздней версией.

Для этого сценария в AD FS 2016 были добавлены специальные ValueType () и escape-символ (\x22). Ниже приведен пример для правила выдачи, а также окончательные выходные данные маркера доступа.

Пример правила выдачи:

Утверждение, выданное в маркере доступа:

В AD FS для Windows Server 2019 можно передать значение ресурса, внедренное в параметр области. Параметр области можно упорядочить в виде списка с разделителями-пробелами, где каждая запись представляет собой структуру из ресурса и области.

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

Поддерживается:

• aza. Если вы используете расширения протокола OAuth 2.0 для клиентов брокера и параметр области содержит область aza, сервер выдает новый основной маркер обновления и устанавливает его в поле ответа refresh_token. Он также задает для поля refresh_token_expires_in время существования нового основного маркера обновления, если он применяется.
• openid. Эта область позволяет приложению запрашивать использование протокола авторизации OpenID Connect.
• logon_cert. Эта область позволяет приложению запрашивать сертификаты входа в систему, которые можно использовать для интерактивного входа пользователей, прошедших проверку подлинности. Сервер AD FS игнорирует указанный в ответе параметр access_token и вместо него предоставляет цепочку сертификатов CMS в кодировке Base64 или полный ответ PKI. Дополнительные сведения см. в разделе об обработке запроса.
• user_impersonation. Эта область необходима для запроса маркера доступа от имени AD FS. Дополнительные сведения об использовании этой области см. в статье Создание многоуровневого приложения с использованием OBO, OAuth и AD FS 2016 или более поздней версии.

Не поддерживается:

• vpn_cert. Область позволяет приложению запрашивать сертификаты VPN, которые можно использовать для установки VPN-подключений с использованием проверки подлинности по EAP-TLS. Эта область больше не поддерживается.
• электронную почту. Эта область позволяет приложению запрашивать утверждение по электронной почте для пользователя, выполнившего вход. Эта область больше не поддерживается.
• profile. Область позволяет приложению запрашивать утверждения, связанные с профилем пользователя, который выполнил вход. Эта область больше не поддерживается.

Поведение многофакторной проверки подлинности (MFA)

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

AD FS при получении запроса на проверку подлинности сначала определяет, существует ли контекст единого входа (например, файл cookie), а затем, если требуется MFA (например, если запрос поступает из-за пределов), он будет оценивать, содержит ли контекст единого входа MFA. В противном случае будет предложено указать MFA.

Требования к прокси

• Для доступа к экстрасети необходимо развернуть службу роли прокси-службы веб приложения — часть роли сервера удаленного доступа.

• Сторонние прокси-серверы должны поддерживать протокол MS-ADFSPIP в качестве прокси AD FS. Список сторонних поставщиков см. в разделе вопросов и ответов.

• Для AD FS 2016 требуется, чтобы прокси-служба веб-приложений работала под управлением Windows Server 2016. Прокси нижнего уровня невозможно настроить для фермы AD FS 2016, которая работает на уровне поведения фермы 2016.

• Сервер федерации и служба роли прокси-службы веб-приложений не могут быть установлены на одном компьютере.

разрешить пользователям Office 365 доступ к SharePoint в сети

После включения и настройки ПССО в AD FS AD FS будет записывать постоянный файл cookie после того, как пользователь прошел проверку подлинности. Когда пользователь поступает в следующий раз, если постоянный файл cookie по-прежнему действителен, пользователю не нужно предоставлять учетные данные для повторной проверки подлинности. кроме того, можно избежать дополнительного запроса проверки подлинности для Office 365 и SharePoint пользователей в сети, настроив следующие два правила утверждений в AD FS для активации сохраняемости в Microsoft Azure AD и SharePoint в сети. чтобы разрешить пссо пользователям Office 365 доступ к SharePoint в сети, необходимо установить это исправление , которое также входит в состав накопительного пакета обновления 2014 августа для Windows RT 8,1, Windows 8.1 и Windows Server 2012 R2.

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

Итоги:

Единый интерфейс SignOn	ADFS 2012 R2 Зарегистрировано ли устройство?		ADFS 2016 Зарегистрировано ли устройство?
	NO	НЕТ, но функции «оставаться	YES		NO	НЕТ, но функции «оставаться	YES
SSO = > задать токен обновления =>	8 часов	Недоступно	Н/Д		8 часов	Недоступно	Н/Д
ПССО = > задать токен обновления =>	Н/Д	24 часа	7 дней		Н/Д	24 часа	Максимум 90 дней в течение 14 дней
Token Lifetime	1 час	1 час	1 час		1 час	1 час	1 час

Проверка для проверки

Перед продолжением развертывания проверьте результаты развертывания, просмотрев следующие элементы:

• Убедитесь, что ферма AD FS использует правильную конфигурацию базу данных.
• Убедитесь, что ферма AD FS имеет достаточное число узлов и нагрузка на нее будет правильно сбалансирована для ожидаемой нагрузки.
• Убедитесь, что на все серверы AD FS в ферме установлены последние обновления.
• Убедитесь, что все серверы AD FS имеют действительный сертификат проверки подлинности
  • Субъект сертификата — это общее имя (полное доменное имя) узла или подстановочное имя.
  • Альтернативное имя сертификата содержит подстановочное имя или полное доменное имя службы федераций

Поддерживаемые типы отдельных Sign-On

AD FS поддерживает несколько типов единого Sign-Onного взаимодействия:

• Единый вход сеанса

  Файлы cookie единого входа сеанса записываются для пользователя, прошедшего проверку подлинности, что устраняет дальнейшие запросы, когда пользователь переключает приложения в течение определенного сеанса. Однако если определенный сеанс завершается, пользователь снова получит запрос на ввод учетных данных.

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

• Постоянный единый вход

  Файлы cookie постоянного единого входа записываются для пользователя, прошедшего проверку подлинности, что исключает дальнейшие запросы, когда пользователь переключает приложения в течение срока действия файла cookie постоянного единого входа. Различие между постоянным SSO и ВХОДом в сеансе заключается в том, что постоянный единый вход можно поддерживать в разных сеансах.

  Если устройство зарегистрировано, AD FS задаст файлы cookie для постоянного единого входа. AD FS также задает файл cookie для постоянного единого входа, если пользователь выбрал параметр «оставаться в системе». Если файл cookie постоянного единого входа не является допустимым, он будет отклонен и удален.

• Единый вход для конкретного приложения

  В сценарии OAuth маркер обновления используется для сохранения состояния единого входа пользователя в области конкретного приложения.

  Если устройство зарегистрировано, AD FS установит срок действия маркера обновления на основе постоянного времени существования файлов cookie единого входа для зарегистрированного устройства, которое по умолчанию составляет 7 дней для AD FS 2012 R2 и не более 90 дней с AD FS 2016, если они используют устройство для доступа к AD FS ресурсам в течение 14 дней.

Если устройство не зарегистрировано, но пользователь выбрал параметр «оставаться в системе», срок действия маркера обновления будет равным времени существования файлов cookie для постоянного единого входа, который по умолчанию составляет 1 день и не может превышать 7 дней. В противном случае время существования маркера обновления равно времени существования cookie единого входа сеанса, которое по умолчанию составляет 8 часов

Как упоминалось выше, пользователи зарегистрированных устройств всегда будут получать постоянный единый вход, если только не отключен постоянный единый вход. Для незарегистрированных устройств можно добиться постоянного единого входа, включив функцию «оставаться в системе» (функции «оставаться).

для Windows Server 2012 R2, чтобы включить пссо для сценария «оставаться в системе», необходимо установить это исправление , которое также входит в состав накопительного пакета обновления 2014 августа для Windows RT 8,1, Windows 8.1 и Windows Server 2012 R2.

Задача	PowerShell	Описание
Включить или отключить постоянный единый вход		Постоянный единый вход включен по умолчанию. Если она отключена, файл cookie ПССО не записывается.
«Включить/отключить» оставаться в системе «		Функция «оставаться в системе» отключена по умолчанию. Если он включен, конечный пользователь увидит вариант «оставаться в системе» на AD FS странице входа.

Windows Communication Foundation and Windows Identity Foundation messages

In addition to trace logging, sometimes you may need to view Windows Communication Foundation (WCF) and Windows Identity Foundation (WIF) messages in order to troubleshoot an issue. This can be done by modifying the Microsoft.IdentityServer.ServiceHost.Exe.Config file on the AD FS server.

This file is located in <%system root%>\Windows\ADFS and is in XML format. The relevant portions of the file are shown below:

After you apply these changes, save the configuration, and restart the AD FS service. After you enable these traces by setting the appropriate switches, they will appear in the AD FS trace log in the Windows Event Viewer.

Дополнительные серверы федерации

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

Сертификат проверки подлинности сервера

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

Установка дополнительных серверов

Добавление серверов федерации к существующей ферме AD FS начинается с установки всех обновлений на сервер, включая обновление Windows Server 2016, которое необходимо для поддержки развертываний Windows Hello для бизнеса (https://aka.ms/whfbadfs1703). Затем установите роль службы федерации Active Directory (AD FS) на дополнительные серверы и настройте сервер в качестве дополнительного сервера в существующей ферме.

Better Sign-in experience

Customize sign in experience for AD FS applications

We heard from you that the ability to customize the logon experience for each application would be a great usability improvement, especially for organizations who provide sign on for applications that represent multiple different companies or brands.

Previously, AD FS in Windows Server 2012 R2 provided a common sign on experience for all relying party applications, with the ability to customize a subset of text based content per application. With Windows Server 2016, you can customize not only the messages, but images, logo and web theme per application. Additionally, you can create new, custom web themes and apply these per relying party.

For more information see AD FS user sign-in customization.

Преимущества Azure AD

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

Пользователи также могут проходить проверку подлинности непосредственно в локальной Active Directory. Службы федерации Active Directory (AD FS) — это локальная служба идентификации на основе стандартов. Она расширяет возможности использования функции единого входа (SSO) между доверенными бизнес-партнерами, чтобы пользователям не требовалось выполнять вход отдельно для каждого приложения. Это называется федеративной идентификацией.

Во многих организациях есть приложения «программное обеспечение как услуга» (SaaS) или пользовательские бизнес-приложения, интегрированные непосредственно в AD FS, наряду с приложениями на основе Microsoft 365 и Azure AD.

Важно!

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

Мощный инструмент

Как вы видели в этой статье, ADFS 2.0 STS предоставляет простое готовое решение для поддержки заявок в ваших WCF-сервисах и приложениях на основе браузеров. Сам STS является не более чем малой частью ADFS 2.0, которая также включает систему обеспечения CardSpace, механизм преобразований на основе правил, инфраструктуру автоматизированного управления доверительными отношениями, сервисы управления и конфигурирования вместе с соответствующими средствами. В сочетании с WIF служба ADFS 2.0 становится мощным инструментом для программирования решений в области идентификации на платформе Windows.

Зульфигар АхмедЗульфигар Ахмед (Zulfiqar Ahmed) — старший консультант в группе UK Application Development Consulting (ADC).С ним можно связаться через веб-сайт http://zamd.net