Глава 14. Службы Федерализации Active Directory

Rebeladmin Inc. выступает поставщиком ИТ услуг. Существует множество потребителей, которые применяют различные ИТ и базирующиеся в облачном решении службы от этой компании. В последнее время эта компания предложила панель управления на веб основе, в которой пользователи могут зарегистрироваться и управлять своими ресурсами. То же самое приложение применяется внутренними сотрудниками для управления службами инфраструктуры. Для управления идентификацией Rebeladmin Inc. применяет Active Directory Domain Services (AD DS). Когда в этом портале регистрируется внутренний ИТ сотрудник, они не запрашивают какие бы то ни было подробности регистрации. Это обусловлено тем, что данное веб приложение для разрешения доступа применяет Integrated Windows Authentication (IWA, Интегрированную с Windows аутентификацию).

Это процесс также носит название аутентификации NTLM или доменной аутентификации. Он изначально не выдаёт приглашения для регистрационных сведений и не передаёт хэшированных сведений относительно подключённого в настоящий момент пользователя в веб сервер для проверки его разрешения. Этот веб сервер присоединён к домену и данное приложение само по себе интегрировано с Active Directory. Теперь желают получить доступ к тому же самому порталу для управления их рабочими нагрузками пользователи Depache solution.

Имеются два пути обеспечения их этим:

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

Ответом на все эти нюансы является федеративные доверительные отношения. Говоря простым языком, федеративная служба это некая услуга, которая выполняет идентификацию пользователей у своего IdP (Identity Provider, поставщика идентификации) и предоставляет доступ к приложению на основе заявки (требования, claim) от SP (Service Provider, поставщика услуги). Имеется большое число поставщиков федеративной службы, а федеративная служба Microsoft носит название AD FS (Active Directory Federation Services, федеративных служб Active Directory):

В нашем предыдущем примере, Rebeladmin Inc. для управления идентификацией применяет AD DS. Её пользователи используют размещённое там веб приложение (MyHostedApp1) от поставщика облачной службы. Для создания доверительных отношений между Rebeladmin Inc. и SP Rebeladmin Inc. пользуется AD FS. Это позволяет пользователям Rebeladmin Inc. запускать MyHostedApp1 при помощи своих собственных полномочий Windows. При такой установке наша федеративная служба размещается в инфраструктуре самой Rebeladmin Inc. и она превращается в IdP. С точки зрения AD FS это также носит название Claims Provider (CP, Поставщика заявок). Все пользователи выполняют аутентификацию через CP. Сами производители, которые размещают данное приложение также обладают своей собственной инфраструктурой идентификации. Такой производитель приложения превращается в SP, также именуемого как Relying Party (RP, проверяющая сторона) в федеративных доверительных отношениях и такая зависимость в рассматриваемой заявке предоставляется федеративной службе на разрешение/ запрет доступа к данному приложению. К тому же, данная настройка требует открытым лишь TCP порт 443.

Даже несмотря на то что такое соединение носит название доверенного, оно не может применяться взамен Active Directory. Когда установлено доверительное отношение Active Directory, администраторы способны управлять доступом к ресурсам со стороны удалённых пользователей в точности так же, как это выполнялось для внутренних пользователей. Пользователям может быть разрешён доступ к папкам и файлам на основании полномочий NTFS (New Technology File System). Пользователям могут предоставляться полномочия для регистрации в устройствах. Любое работающее с внутренними пользователями приложение может быть также настроено и для разрешения доступа удалённым пользователям. Однако в федеративной среде, доступ может быть разрешён лишь для осведомлённых о заявках (claim-aware) приложений. Заявка это просто некий атрибут и соотносимое значение. В качестве примера, некая заявка может обладать атрибутом username и его значением, dfrancis. Установленная федеративная служба запросит доступ от SP на основании такой заявки. Если приложение данного SP на понимает заявки, оно не сможет принять решение разрешать или запрещать доступ:

Давайте повторно рассмотрим свой предыдущий пример с подробным описанием,

В нашем предыдущем сценарии необходимые федеративные доверительные отношения выполняются напрямую самим приложением. Однако при некоторых обстоятельствах наш Поставщик услуги (SP) также будет обладать средой своей федеративной службы со своей стороны. В основном это имеет место когда такой Поставщик услуг обладает множеством клиентов с федеративными доверительными отношениями. В данном случае происходит следующее:

В своём предыдущем примере я несколько раз упоминал "заявки" (требования, claims). Однако что именно представляет собой заявка и как она формируется?

Заявка (claim) это просто предложение о пользователе, которое применяется для целей авторизации поддерживающих заявки приложений. Каждая заявка содержит значения для пользователя, такие как их UPN (имя участника- пользователя), адрес электронной почты и Common Name (CN, стандартное имя).

AD FS поддерживает множество различных типов заявок. Типы заявок применяются чтобы отобразить какой вид значения будет включён в эту заявку. Приводимая ниже таблица содержит наиболее распространённые типы заявок:

Таблица 14-1. Типы заявок

Тип заявки	Описание
UPN	Значение UPN этого пользователя
Email	Адрес электронной почты с типом RFC 5322
Given name	Именование пользователя
CN	Значение CN учётной записи пользователя
Name	Имя пользователя
Surname	Фамилия пользователя
Windows account name	Учётная запись в формате домен/пользователь
Group	Группа, к которой относится пользователь
Role	Роль пользователя
AD FS 1.x UPN	UPN пользователя при взаимодействии с AD FS 1.x
AD FS 1.x UPN email address	Адрес электронной почты с типом RFC 5322 при взаимодействии с AD FS 1.x

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

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

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

В рассматриваемой федеративной среде значения IdP (Поставщика идентификации) и SP (Поставщика услуги) нуждаются в обмене данными аутентификации и авторизации. SAML (Security Assertion Markup Language, Язык разметки утверждений безопасности) жто открытый стандарт на основе XML, который применяется для передачи полномочий от IdP к SP. Этот стандарт впервые был предложен OASIS Security Services Technical Committee и его последняя доступная версия это 2.0. Этот стандарт обычно используется многими поставщиками федеративных служб разработчиками приложений для предоставления некой практики SSO. Его запрос заявки и обработка заявки в точности те же самые, по сравнению с применявшимися нами в предыдущем разделе, с единственным отличием, состоящем в отличии самого формата его маркера запроса и отклика. SAML применяет в качестве своего маркера подписанный файл XML. В терминологии SAML, те маркеры, которые вырабатываются на стороне Поставщика идентификации, носят название asserts (выставлением утверждений), а собственно расшифровка и обработка установки утверждений на стороне Поставщика услуги именуется assertion (получения утверждения).

Это часть множества стандартов WS*, включая WS-Security, WS-Federation и сами политики WS-Security. WS это сокращение для Web Services. WS-Trust определяет ото протокол, который применяется при запросах и выпуске маркеров безопасности со стороны WS-Security. STS (Security Token Service, Служба безопасных маркеров) это большая функциональность WS-Trust и она может применяться для преобразования выпущенных локально маркеров безопасности в прочие форматы маркеров безопасности, которые могут обрабатываться вашим приложением. Она также способна преобразовывать приходящие маркеры безопасности в поддерживаемые форматы маркеров.

WS-Federation это также часть стандартов WS*. В то время как SAML работает лишь с маркерами SAML, WS-Federation поддерживает применение большого числа типов маркеров, включая SAML. В целом, WS-Federation предоставляет некий механизм упрощения взаимодействия между Поставщиком идентификации и Поставщиком услуги. Самая основополагающая цель WS-Federation состоит в упрощении разработки федеративных служб посредством взаимодействия по всем областям (realm) и управления федеративными службами при помощи повторного применения модели и протокола STS WS-Trust. Дополнительные сведения относительно WS-Federation можно найти в https://ibm.co/3CGyRbO.

Прежде чем мы установим роль AD FS, имеется неколько связанных с ней компонентов, о которых надлежит иметь сведения. Вплоть до Windows Server 2012 R2 имелось четыре службы роли AD FS: служба федерализации, посредник службы федерализации, поддерживающий заявки агент и агент на соновании маркеров Windows (который поддерживал взаимодейтвие AD FS 1.x). Они более не доступны в качестве служб роли и когда мы устанавливаем AD FS, будет иметься лишь роль службы федерализации.

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

AD FS 1.0

Впервые AD FS была введена в Windows Server 2003 R2. Эта версия AD FS более не доступна, поскольку Windows Server 2003 превзошёл своё время жизни. Она поддерживала базовые возможности SSO. Она обладала меньшей совместимостью с прочими присутствующими на рынке поставщиками служб федерализации.

AD FS 1.1

Была предложена в Windows Server 2008 и продолжена в Windows Server 2008 R2. Она не сильно изменилась по сравнению с версией 1.0. Она также страдала предоставлением ограниченной поддержки для прочих служб федерализации. Она поддерживала лишь пассивный профиль WS-Federation и SAML 1.0.

AD FS 2.0

Данная версия была выпущена после Windows Server 2008 R2, однако в качестве отдельной установки. Все прочие версии поставлялись ка часть самой ОС. Вплоть до версии 2.0 они поддерживали для своего хранилища аутентификации применение AD LDS. Это означало, что пользователи могли выполнять аутентификацию при помощи AD LDS, аналогично Active Directory. Начиая с версии 2.0, LDS больше не поддерживается в качестве хранилища учётных записей. Она способна работать как хранилище атрибутов, которое способно хранить данные AD FS, но не может применяться для аутентификации. AD FS 2.0 к тому же поддерживает среду доменов родитель- потомок, поэтому пользователи из дочернего домена для федерализации способны применять AD FS в другом домене.

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

AD FS 2.1

Эта версия поступала с Windows Server 2012 и не обладала существенными изменениями по сравнению с версией 2.0.

AD FS 3.0

Данная версия была введена в Windows Server 2012 R2. Она удалила службу посредника AD FS из AD FS 2.0 и заменила её на WAP (Web Application Proxy, посредника веб приложений). Он работал из DMZ (Demilitarized Zone) и не нуждался в присоединении к домену. Основная его идея состояла в защите самой инфраструктуры идентификации от поддельных маркеров. К тому же, были удалены веб агенты AD FS 1.x, которые предоставляли подключения к прочим системам.

Workspace Join это одна из величайших функциональных возможностей, поступивших с AD FS 3.0. Это позволило нам регистрировать мобильные устройства (даже не-Windows) в компании или организации для доступа к приложениям и данным при помощи SSO. AD FS 3.0 более вовсе не требует IIS (Internet Information Services) и устанавливается как отдельная роль. Она также поддерживает gMSA (group Managed Service Account, учётную запись управляемой группой службы). Это новый тип учётной записи службы, который поддерживает автоматическое изменение паролей. Создание таких учётных записей и управление ими пояснялось в Главе 8, Управление пользователями, группами и устройствами. Данная версия также поддерживает маркеры доступа стандарта OAuth 2.0. Это маркеры в формате JSON и их проще применять в современных приложениях.

AD FS 4.0

AD FS 4.0 это самая последняя версия, доступная в Windows Server 2016/ 2019/ 2022. Именно ею мы пользуемся на протяжении этой главы. Данная версия поддерживается требованиями современных гибридных облачных решений. Если вы уже применяете Azure AD, эта версия позволяет вам применять Microsoft Azure MFA без установки и настройки дополнительных компонентов. В предыдущих версиях AD FS было необходимо настраивать дополнительный сервер. В этой новой версии AD FS обладает встроенным адаптером Azure MFA. Аналогично AD FS 3.0, эта новая версия также поддерживает регистрацию мобильных устройств для поддержки требований совместимости организации. Если это не среда Azure AD, тогда при помощи AD FS 4.0 вы способны применять условные политики к компонентам площадки.

К тому же эта версия поддерживает современные стандарты аутентификации, такие как OpenID Connect и OAuth 2.0.

Она предоставляет расширенную практику пользователя с Windows 10, а также с последними прикладными приложениями Android и iOS. AD FS также поддерживает аутентификацию при помощи совместимых с v3.0 LDAP каталогов. Он позволяет персоналу применять AD FS снова и снова, даже если у них не запущена AD DS. Windows 10 представил свои новые методы регистрации без пароля Windows Hello и Microsoft Passport. Они основываются на вводе PIN и биометрии, например, отпечатках пальцев и распознавании лиц. AD FS 4.0 поддерживает эти новые методы подписи.

Также была упрощена миграция с AD FS 2012 R2. Ранее, если нам было необходимо выполнять миграцию с одной версии на другую, нам требовалось параллельно с промышленной фермой AD FS строить некую ферму и затем выполнять миграцию своей конфигурации. Однако в нашей новой версии мы можем вводить вой сервер AD FS 2022 в уже имеющуюся ферму Windows Server 2012 R2 и он приступит к работе на операционном уровне Windows Server 2012 R2. После того как все Windows Server 2012 R2 удалены из вашей фермы, её операционный уровень может быть обновлён до Windows Server 2022.

Насколько нам известно, AD DS 2022 не обладает значительными изменениями по сравнению с AD DS 2019. Даже нет никакого нового уровня функциональности Леса или домена. То же самое применимо и к AD FS 2022. Ниже я перечислил некоторые имеющиеся у AD FS 2019 расширения. Они также применимы и к AD FS 2022:

Дополнительные сведения о прочих функциональных возможностях и исправлении ошибок доступны в https://bit.ly/3FLLy6T

Мы пользуемся серверами посредниками (прокси) для доступа в Интернет по той причине, что они осуществляют необходимое взаимодействие с Интернетом от имени внутренних пользователей и защищают последних от внешних угроз. Web Application Proxy (WAP) позволяет нам публиковать веб приложения (включая AD FS) для общего доступа без выставления туда самих серверов. Эта роль более не является частью AD FS и она поставляется как часть роли удалённого доступа. Для своей работы AD FS не требуется Web Application Proxy, однако рекомендуется применять его, когда пользователи регистрируются из внешних сетевых сред. К тому же он предоставляет базовую защиту от Denial-of-Service (DoS) путём дросселирования и подавления шумов подключений.

Сами взаимодействия между серверами- посредниками и веб клиентами зашифрованы (на основе SSL). Установка Web Application Proxy не поддерживается в том же самом сервере, что и AD FS. Он не обладает встроенными возможностями балансировки нагрузки. Если необходима балансировка нагрузки, её можно выполнить при помощи любого поддерживаемого балансировщика нагрузок на программной основе или в аппаратной реализации.

Настройки конфигурации AD FS необходимо сохранять в базе данных. AD FS поддерживает два типа баз данных. Самый простой метод состоит в применении Windows Internal Database (WID), которая поставляется вместе с установкой AD FS. Это не обособленная установка базы данных и имеется возможность предоставления высокой доступности путём копирования баз данных в другие серверы из имеющейся фермы AD FS. Когда мы доходим до настроек AD FS, нам выдаются два варианта развёртывания:

Если WID применяется с первым вариантом, тогда WID будет развёрнут с масштабированием, которое позволит серверам позднее добавляться в общую фермы и реплицировать WID. Самый первый сервер из этой фермы будет первичным сервером и он будет размещать копию чтения/ записи своей базы данных.

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

AD FS способна хранить данные конфигурации в Microsoft SQL. Это расширяет показатели производительности имеющейся фермы AD FS, в особенности, когда имеет место бо́льшая обработка, поскольку она способна считывать и записывать данные быстрее. В отличии от WID, мы можем добавить в соответствующий экземпляр SQL высокую доступность применяя метод кластеризации SQL или метод Always On {Прим. пер.: подробнее в нашем переводе SQL Server 2016 с высокой доступностью... Поль Бертуччи, Pearson Education, Inc., 2018.}. Когда AD FS применяет MS SQL, тогда каждый сервер из фермы обладает доступом на чтение/ запись к своей базе данных. Это также делает возможным поддержку таких функциональных возможностей как разрешение артефактов SAML и выявление повторного воспроизведения маркера SAML/WS-Federation. Обе эти возможности требуют настроек, которые сохраняются в совместно используемой базе данных вместо WID.

Имеется несколько различных моделей развёртывания, которыми мы можем воспользоваться для развёртывания AD FS:

В этом разделе мы намерены рассмотреть эти различные топологии и их характеристики.

Это самая простая из доступных модель развёртывания AD FS. Она содержит единственный сервер AD FS. Она не обладает высокой доступностью (если только та имеется на уровне хоста).

Она идеальна для среды лаборатории или среды постановки:

В нашем предыдущем примере у нас имелось веб приложение, myapp.rebeladmin.com, которому требуется разрешать доступ через AD FS. У нас имеется один сервер AD FS в установке с WID. Он пребывает за корпоративным межсетевым экраном, а также присутствует Network Address Translation (NAT, Трансляция сетевых адресов)и размещены правила доступа для выполнения следующего:

Наше приложение также должно обладать настроенными уместными внешними и внутренними записями DNS. Когда запрос поступает из внешней сетевой среды, он должен разрешить общедоступный IP адрес, а если запрос приходит из внутренней сетевой среды, DNS должен разрешать соответствующий внутренний IP адрес. Это также носит название расщепление сознания (split- brain) DNS.

Я рекомендую для такой настройки выполнять конфигурацию ваш сервер AD FS c Network Load Balancer (NLB) Windows. Это будет стоить вам всего лишь одного дополнительного IP адреса под IP кластера NLB, однако когда нам потребуется расширять свою ферму AD FS, всё что нам потребуется, это настроить другой сервер и добавить его к NLB. Значение IP кластера будет соответствовать общедоступному IP, и он будет применяться с некой внешней записью DNS для AD FS.

При данной установке Web Application Proxy не применялся:

Таблица 14-2. Единственный сервер федерализации

Преимущества	Недостатки
Низкая стоимость реализации. Для AD FS требуется лишь один сервер и никаких лицензий SQL не применялось, поскольку использовался WID.	Отсутствует избыточность. Единственная точка отказа.
Простота в управлении.	Плохая производительность, поскольку не имеется способа совместного применения нагрузок.
Нет дополнительной интеграции роли службы, а следовательно меньше зависимостей.	Меньшая безопасность, поскольку невозможно ретранслировать запросы в ваш сервер AD FS и данный метод пользуется непосредственной точкой подключения для обработки запросов (отсутствует Web Application Proxy).
Всё ещё имеется возможность настройки расширений свойств и можно добавлять серверы в ферму AD FS когда пожелаете.	N/A

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

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

При данной установке мы можем разделить функциональность своей сетевой среды между периметром и корпоративными сетями. Наша предыдущая настройка требовала правил NAT и доступа для выполнения следующих требований взаимодействия:

В нашем предыдущем примере, после того как внешний пользователь выполняет доступ к URL приложения, он будет перенаправлен к серверу Web Application Proxy. Он не обязательно должен быть присоединённым к домену, поскольку он работает из сетевой среды периметра. Серверы посредники должны быть способны разрешать необходимые имена DNS для наших серверов AD FS из сетевой среды периметра. Это может быть выполнено при помощи сервера DNS или файла host.

Аналогично предыдущей модели, это может быть реализовано при помощи NLB (балансировки сетевой нагрузки) чтобы допустить будущее расширение с минимальным воздействием. Для этого нам необходимо два кластера NLB. Первый кластер NLB служит для Web Application Proxy, а второй кластер NLB служит для серверов AD FS. Единственное изменения состоят в соответствующих записях DNS и правилах межсетевого экрана. Вместо указания DNS и правил межсетевого экрана на соответствующие адреса IP, нам необходимо применять IP адреса кластера NLB:

Таблица 14-3. Единственные сервер федерализации и WAP

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

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

До сих пор мы рассматривали режимы, которые получают преимущества от простоты реализации и улучшения безопасности. Однако данная модель сосредоточена на высокой доступности. Каждая роль вудет настроена с кластерами NLB. База данных AD FS для целей высокой доступности будет размещена в среде кластера SQL Always On {Прим. пер.: подробнее в нашем переводе SQL Server 2016 с высокой доступностью... Поль Бертуччи, Pearson Education, Inc., 2018.}. Эта модель идеальна для Поставщика услуг (SP) и прочих систем ведения дел, которые работают с большими объёмами запросов AD FS.

Приводимая ниже схема предоставляет образец проекта для данной технологии:

Аналогично нашей предыдущей модели, работа этой модели отчётливо делится на два сетевых сегмента: периметра и корпоративный. Межсетевой экран должен обладать правилами NAT и доступа для поддержки следующих требований:

Для обоих кластеров NLB начальной точкой подключения будет IP соответствующего кластера NLB. Помимо внешнего URL самого приложения, единственным общедоступным URL будет URL Web Application Proxy. В нашем предыдущем примере для secure.rebeladmin.com установлено соответствие к IP NLB кластера Web Application Proxy.

Серверы AD FS применяют группу доступности Microsoft SQL Always On для размещения базы данных AD FS. Это база данных для чтения/ записи в обоих хостах.

Таблица 14-4. Множество серверов федерализации и множество серверов WAP с применением Сервера SQL

Преимущества	Недостатки
Высокая доступность: Каждый компонент размещён во множестве серверов с балансировкой нагрузки. База данных AD FS также пользуется высокой доступностью среды SQL.	Высокая стоимость: Требуется множество серверов и лицензий (ОС, SQL сервер). Здесь также увеличивается стоимость сопровождения.
Высокая производительность: Рабочие нагрузки распределяются между множеством хостов при помощи балансировщиков нагрузки.	Сложность установки: Собственно реализация затратна по времени и требует дополнительных навыков по планированию и настройке.
Поддерживает такие функциональные возможности как разрешение артефактов SAML и выявления повторения маркеров SAML/ WS-Federation.	Поиск и устранение некой проблемы затратно по времени и сложно выполнимо, поскольку имеется большое число систем и зависимостей.

Мы просто прошлись по различным моделям развёртывания и взвесили их за и против. Наш следующий этап состоит в рассмотрении самого процесса настройки AD FS.

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

Помимо этого нам также нужны в своём межсетевом экране определённые правила NAT и доступа. Однако здесь я не намерен обсуждать эти подробности, поскольку я раскрыл их когда я пояснял топологии в предыдущем разделе.

Нам требуется обладать несколькими записями DNS (внутренними и внешними), настроенными перед записью и развёртыванием:

Таблица 14-5. Настройки DNS

Запись DNS	Внешняя	Внутренняя
URL приложения	Да	Да
URL WAP	Да	N/A
URL AD FS	N/A	Да

В этой демонстрационной среде мы воспользуемся следующими URL:

Развёртывание AD FS нуждается в нескольких сертификатах SSL.

В своей демонстрации мы применим следующие:

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

dir Cert:\LocalMachine\My
		

Наш следующий шаг состоит в установке службы роли AD FS, что можно выполнить при помощи приводимой ниже команды PowerShell:

Install-WindowsFeature ADFS-Federation -IncludeManagementTools
		

Следующий далее снимок экрана отображает вывод нашей предыдущей команды:

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

Import-Module ADFS
$credentials = Get-Credential
Install-AdfsFarm `
-CertificateThumbprint:"938E369FA88B2F884A5BBC495F2338BE9FA0E0BB" `
-FederationServiceDisplayName:"REBELADMIN INC" `
-FederationServiceName:"adfs.rebeladmin.com" `
-ServiceAccountCredential $credentials
		

В данной установке мы пользуемся для AD FS WID, поэтому нам нет нужды настраивать SQL. В приведённой выше команде CertificateThumbprint определяет необходимый сертификат SSL (adfs.rebeladmin.com), а FederationServiceDisplayName задаёт отображаемое название нашей службы федерализации. FederationServiceName это название самой службы, и оно должно соответствовать применяемому нами SSL. ServiceAccountCredential применяется для определения подробностей учётной записи службы под установку AD FS. По окончанию необходимо выполнить перезапуск системы для применения этой конфигурации:

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

Get-WinEvent "AD FS/Admin" | Where-Object {$_.ID -eq "100"} | fl
		

Она выдаст на печать содержимое события 100, которое и подтверждает успешность установки AD FS.

Наш следующий этап конфигурации заключается в установке WAP. Он не обязан быть присоединённым к домену сервером и обязан размещаться в сетевой среде периметра. Перед самим процессом установки настроим необходимые сертификаты. В моей демонстрации это касается *.rebeladmin.com. Мы можем проверить их при помощи следующего:

dir Cert:\LocalMachine\My
		

Прежде чем продолжить, нам также требуется проверить способен ли сервер разрешать adfs.rebeladmin.com в качестве WAP, необходимого для подключения AD FS.

После того как всё подтверждено, мы можем установить роль WAP:

Install-WindowsFeature Web-Application-Proxy -IncludeManagementTools
		

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

$credentials = Get-Credential
Install-WebApplicationProxy
-FederationServiceName "adfs.rebeladmin.com"
-FederationServiceTrustCredential $credentials
-CertificateThumbprint "3E0ED21E43BEB1E44AD9C252A92AD5AFB8E5722E"
		

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

Параметр CertificateThumbprint применяется для определения необходимого WAP сертификата. В нашей демонстрации это сертификат *.rebeladmin.com. В самом конце настройки нам необходимо перезапустить свою систему для применения изменений.

По завершению перезапуска мы можем подтвердить жизнеспособность своей конфигурации, воспользовавшись приводимым ниже событием из журнала в своём сервере AD FS:

Get-WinEvent "AD FS/Admin" | Where-Object {$_.ID -eq "396"} | fl
		

В самом начале данной главы я пояснял , что не все приложения могут для авторизации применять AD FS. Это должно быть приложение, способное применять заявки. У меня имеется приложение с названием myapp.rebeladmin.com, которое уже установлено. При его настройке я установил его на применение имеющейся STS и добавил метаданные URL своего нового сервера AD FS, а именно, https://adfs.rebeladmin.com/federationmetadata/2007-06/federationmetadata.xml.

После того как это приложение настроено, когда я перейду к своему приложению , а именно, https://myapp.rebeladmin.com/myapp (в внутренней сети), я смогу обнаружить приводимую ниже ошибку. Она обусловлена тем, что что настройка AD FS, ожидаемо, не знает пока о моём приложении:

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

Для этого выполним следующие шаги:

Теперь у нас имеется настроенное при помощи AD FS приложение. Однако наше требование состоит в применении Web Application Proxy для публикации своего приложения в общий доступ.

Для этого зарегистрируемся в своём сервере Web Application Proxy в качестве администратора и выполним такую команду:

Add-WebApplicationProxyApplication
-BackendServerUrl 'https://myapp.rebeladmin.com/myapp/'
-ExternalCertificateThumbprint
'3E0ED21E43BEB1E44AD9C252A92AD5AFB8E5722E'
-ExternalUrl 'https://myapp.rebeladmin.com/myapp/'
-Name 'MyApp'
-ExternalPreAuthentication AD FS
-ADFSRelyingPartyName 'myapp.rebeladmin.com'
		

В нашей предыдущей команде ExternalUrl определяет значение внешнего URL для нашего приложения. BackendServerUrl определяет для этого приложения значение внутреннего URL. ExternalCertificateThumbprint это сертификат для его применения во внешних сетях. Параметр Name определяет имя потребителя для данного прикладного приложения, которое будет отображаться на странице proxy. ExternalPreAuthentication определяет сам режим аутентификации. В своей установке мы пользуемся режимом AD FS. также поддерживается режим pass-through. ADFSRelyingPartyName определяет имя проверяющей доверие AD FS стороны, которое будет применяться для этого приложения.

После того как всё выполнено, когда мы выполняем доступ к своему приложению с внешнего URL https://myapp.rebeladmin.com/myapp/, он успешно переправляется посредником к AD FS и, после успешной аутентификации отображается страница самого приложения:

MFA (многофакторная авторизация) это сегодня распространённое требование для Интернет служб, которые могут быть для любых размещаемых в организациях решений, таких как Citrix, RDS и прочих веб приложениях. MFA к тому же применяется в гибридных средах для предоставления одного и того же уровня защиты на площадках и в облачном решении.

На рынке существует множество поставщиков услуг MFA. Некоторые из них являются решениями для площадки, в которых мы можем устанавливать некий прибор и применять услугу MFA. Другие это поставщики облачных решений и они продают MFA в качестве подписок. Потребители могут просто устанавливать некого агента на площадке и подключать его к таким облачным решениям. Azure MFA первым предложил применение служб Azure и последующих улучшений также и для поддержки защиты рабочих нагрузок на площадке. Для аутентификации пользователи могут применять SMS, телефон или PIN в приложении Microsoft Authenticator. Большинство Поставщиков услуг (SP) MFA имеют отдельного агента, которого необходимо устанавливать в ваших серверах AD FSчтобы подключаться к таким службам MFA.

Интеграция Azure MFA была осуществлена в средах Windows Server 2012 R2. Она нуждается в агенте, а также в сервере Azure MFA на площадке. Со средой интеграции AD FS 2016/2019/2022 Azure MFA произошли большие изменения. В AD FS 2016/2019/2022 нам больше нет нужды устанавливать эти компоненты. Для активной доставки необходимой конфигурации адаптер AD FS Azure допускает интеграцию с Azure AD. В этом разделе мы намерены рассмотреть то как мы можем осуществлять интеграцию своей настройки AD FS с Azure MFA.

 

Предварительные требования

Для настройки Azure MFA нам необходимы следующие моменты:

 

Создание сертификата на ферме AD FS для соединения с Azure MFA

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

$certbase64 = New-AdfsAzureMfaTenantCertificate -TenantID 05c6f80c-61d9-44df-bd2d-4414a983c1d4
		

Наша предыдущая команда сгенерирует новый сертификат. TenantID это значение идентификатора имеющейся у вас в Azure подписки. Его можно обнаружить выполнив это:

Login-AzureRmAccount
		

Наша предыдущая команда запросит полномочия для Azure и когда мы их предоставим, она перечислит TenantID:

Это создаст сертификат в Certifcates (Local Computer)):

 

Разрешение подключения серверов AD FS с клиентом Azure MFA

Теперь у нас имеется необходимый сертификат, однако нам следует сообщить клиенту Azure MFA о необходимости применять его в качестве полномочий для соединения с AD FS.

Перед этим нам следует подключиться к Azure AD при помощи PowerShell Azure. Мы можем сделать это, воспользовавшись такой командой:

Connect-MsolService
		

Затем мы получаем приглашение для вашей регистрации и применяем для подключения вашу учётную запись Azure Global Administrator.

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

New-MsolServicePrincipalCredential -AppPrincipalId 981f26a1-7f43-403b-a875-f8b09b8cd720 -Type asymmetric -Usage verify -Value $certbase64
		

В нашей предыдущей команде, AppPrincipalId определяет Globally Unique Identifer (GUID) для нашего клиента Azure MFA.

 

Разрешение определённой ферме AD FS применения Azure MFA

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

Set-AdfsAzureMfaTenant -TenantId 05c6f80c-61d9-44df-bd2d-4414a983c1d4 -ClientId 981f26a1-7f43-403b-a875-f8b09b8cd720
		

В приводимой выше команде TenantId ссылается на идентификатор арендатора Azure, а ClientId представляет клиента Azure MFA.

После успешного выполнения этой команды нам требуется перезапуск своей службы AD FS в каждом из серверов нашей фермы:

 

Разрешение Azure MFA для аутентификации

Наш последний шаг конфигурации состоит во включении Azure MFA глобально для нашего сервера AD FS.

Для этого зарегистрируйтесь в сервере AD FS в качестве Корпоративного администратора. Затем перейдите к Server Manager | Tools | AD FS Management.

Затем, в полученной консоли, перейдите к Service | Authentication Methods. Далее, из панели Actions, кликните по Edit Primary Authentication Method:

Это откроет окно для конфигурации методов глобальной аутентификации. Для этого имеются две вкладки, причём из Azure MFA вы наблюдаем обе. Когда Azure MFA применяется в качестве первичного метода посредством удаления прочих вариантов, тогда AD FS не будет запрашивать регистрации и будет применять MFA в качестве единственного метода аутентификации.

Границы его операций могут быть установлены для внутренней сети или для внешней сети:

Другой вариант для выбора MFA в качестве вторичного метода аутентификации:

Это завершает интеграцию Azure MFA и пользователи могут применить MFA на основе выбранных в нашем предыдущем мастере вариантов.

Azure AD поддерживает различные методы интеграции с Active Directory на площадке. Мы можем настраивать федерализацию между AD FD на площадке и Azure AD для разрешения интеграции между двумя системами. При выполненном размещении федерализации пользователи способны регистрироваться в Azure AD при помощи имени и пароля пользователя Active Directory площадки. Данный метод обеспечивает прохождение аутентификации на площадке. Для настройки необходимой федерализации мы можем применять Azure AD Connect. На протяжении процесса настройки мы можем либо развернуть ноый AD FS сервер/ ферму или настроить имеющиеся серверы AD FS. В этом разделе я намерен продемонстрировать как мы можем настроить подпись федерализации между AD FS и Azure AD. Прежде чем мы перейдём к этому, важно разобраться как в точности работает метод федеративной регистрации.

Rebeladmin Inc. обладает федерализацией между Azure AD и AD FS площадки. Наш пользователь Марк предпринимает попытку подписки доступа к порталу Office 365 при помощи своего браузера. Давайте рассмотрим как работают аутентификация и авторизация при помощи федеративной регистрации:

В своём следующем разделе я намерен продемонстрировать как создавать федеральные доверительные отношения между AD FS и Azure AD.

Приводимая ниже схема поясняет планируемую настройку демонстрации для данного упражнения.

В данной среде демонстрации у меня уже имеется поднятый и работающий контроллер домена Active Directory (PDC01.rebeladmin.com). Здесь в качестве имени домена Active Directory используется rebeladmin.com.

В разделе Развёртывание AD FS из этой главы мы уже демонстрировали как настраивать свою службу AD FS, а потому мы не хотим повторять её здесь. У нас уже имеется настроенной в ADFSSRV01.rebeladmin.com AD FS.

Воспользовавшись Get-AdfsProperties, мы можем просмотреть текущую конфигурацию своего сервера AD FS.

Что касается приведённого выше снимка экрана, мы можем наблюдать свой сервер настроенным с именем службы adfs.rebeladmin.com. Я также разрешаю страницу регистрации AD FS для целей тестирования, применяя Set-AdfsProperties -EnableIdpInitiatedSignonPage $true.

После этого, я имею возможность доступа через Интернет к своей странице регистрации adfs.rebeladmin.com и проверить регистрацию, воспользовавшись учётной записью своего пользователя домена.

Наш следующий этап настройки состоит в конфигурации Azure AD Connect для федерализации.

В данной демонстрационной настройке я намерен установить в PDC01.rebeladmin.com Azure AD Connect. Для этого:

Мы можем приступить к процессу проверки подтверждения состояния настройки Azure AD Connect. Для этого:

Теперь нам требуется проверить свой процесс регистрации. Для выполнения этого:

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

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

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

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

И последнее, но не в отношении значимости, мы изучили как включать федерализацию между Azure AD и AD FS площадки.

В своей следующей главе мы рассмотрим другую службу роли AD, Active Directory Rights Management Service (AD RMS), которую можно применять для защиты чувствительных данных в инфраструктуре.