3-2 Основи планування та адміністрування служб доступу до інформаційних ресурсів / ЛБ / Книга Active directory

которыми устанавливается доверительная связь. Кроме того, между сервером федерации ресурсов, локализованным в сети по периметру, и сервером федерации учетных записей, локализованным во внутренне» сети, устанавливается доверие федерации. В данном сценарии внешние пользователи располагают учетными записями в лесу периметра, а внутренние - во внутреннем лесу Системы AD FS осуществляют федерацию нрав доступа учетных записей из обоих лесов приложению в сети по периметру. По этой причине внутренние пользователи получают доступ к приложениям из внутренней сети и Интернета, а внешние - только из Интернета (рис. 17-5).

Клиент

contoso.com

Рис. 17-5. Использование доверительной связи лесов и доверия федерации дл* предоставления доступа к приложениям в экстрасети

ВНИМАНИЕ! Использование каталогов AD DS в сети периметра

Такой сценарий следует реализовывать очень осторожно. Функция каждой из четырех дополнительных технологий Active Directory (AD LDS, AD CS, AD RMS и ADFS) состоит в расширении полномочий внутренних развертываний AD DS без АП п о " ' " 0 0 ™ В у п 1 > а и л е , , и и внешними лесами AD DS. Управление внешним лесом " р с д с т а в л я с т с °бой определенную степень риска, чего по возможности следует избегать. Кроме того, чтобы создать доверительную связь между внутренним и

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

Компоненты AD FS

Помимо различных служб ролей п технологии AD FS применяются еще несколько компонентой:

•утверждения;

•данные cookies;

•сертификаты.

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

Утверждения AD FS

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

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

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

•Служба федерации запрашивает утверждения и хранилище каталогов (AD DS или AD LDS) и предоставляет их после фильтрации приложению ресурсов.

Технология AD FS поддерживает три типа утверждений.

• Идентификационное утверждение Под эту категорию подпадают все утверждения на основе идентификации пользователя. Для генерирования маркеров безопасности из списка утверждений в каждом утверждении должен присутствовать хотя бы один тип идентификационного утверждения, о Такое утверждение может содержать основное имя пользователя UPN

(User Principal Name), представляющее удостоверение пользователя в формате адреса электронной почты (имя_гшьзоватвля®домвп_учета). Несмотря на то что для учетной записи пользователя могут применяться несколько UPN-имен, лишь одно из них будет использоваться в идентификационном утверждении. Если создать несколько таких идентификационных утверждений с разными UPN-именами, будет задействовано UPN-имя с самым высоким приоритетом,

о Утверждение может содержать адрес электронной почты пользователя

(шия_польэоаателя@почтоаый_домен). Как и п случае с UPN-именами, для идентификационного утверждения электронной почты используется только одни электронный адрес, а все остальные адреса, как правило, перечисляются в настраиваемых утверждениях. Адреса, включаемые

в другие типы идентификационных утверждений, получают приоритет второго уровня,

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

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

К СВЕДЕНИЮ Утверждения AD FS и сопоставление утверждений

Более подробную информацию об утверждениях AD FS и сопоставлении утверждений можно найти по адресу http://technet2.microsofC.com/winrlowsseiver200S/en/

Hbrary/4fd78221-3d2e-4236-a971-18cdb8513d6b1033.mspx?mfr-tme.

Файлы cookie AD FS

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

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

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

Файл cookie для выхода всегда является файлом cookie сеанса. Он не подписывается, не шифруется и удаляется в процессе выполнения операций очистки.

К СВЕДЕНИЮ Файлы cookie AD FS

Более подробную информацию о файлах cookie AD FS можно найти по адресу top://uchnet2.micwwft.com/wmdowssewer2008/an/library/0357bdbc-2l9d-<1ec1-a6d0- 1a3376bc Ш1033.mspx?mfr-true.

Сертификаты AD FS

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

от ее назначения.

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

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

дерации или веб-клиентами. Сертификаты SSL обычно запрашиваются и устанавливаются с помощью диспетчера IIS (IIS Manager).

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

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

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

• П р о к с и - а г е н т ы с л у ж б ы ф е д е р а ц и и Должны располагать сертификатом проверки подлинности сервера для поддержки коммуникаций с шифрованием SSL с веб-клиентами.

О н и также д о л ж н ы располагать сертификатом проверки подлинности клиента д л я аутентификации сервера федерации в процессах коммуникаций. Им может быть любой сертификат проверки подлинности клиента с рас- ш и р е н н ы м использованием ключа EKU (Extended Key Usage). Закрытый и открытый ключи этого сертификата хранятся на прокси. Открытый ключ также хранится на серверах федерации и в политике доверия. В консоли AD FS такие сертификаты также называются сертификатами проксп-агентов службы федерации .

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

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

Более подробную информацию о сертификатах AD FS можно найти по адресу hUp://technet2.microsoft.com/winilowsserver2008/en/libraiy/505507c2-db4a-45(In-ad1b- 082d5484b0c91033.mspx?mfr-true.

СОВЕТ К ЭКЗАМЕНУ

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

8.Протестируйте результаты операции путем передачи пакетов ping с одного сервера на другой. Например, для передачи пакетов ping с м а ш и н ы SER - VER01 на компьютер SERVER06 используйте следующую команду:

ping server01.contoso.com

Вы должны получить ответ с указанием IP-адреса м а ш и н ы S E R V E R 0 1 .

Упражнение 2. Установка серверов ф е д е р а ц и и

Теперь установите серверы федерации. Д л я этого потребуется установить роль сервера и необходимые службы поддержки.

1.Запустите машины SERVER01, SERVER03, S E R V E R 0 6 и S E R V E R 0 7 . Войдите на машину SERVER07 как администратор домена.

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

2. В программной группе Администрирование (Administrative Tools) запустите Диспетчер сервера (Server Manager).

3. На панели дерева щелкните правой кнопкой м ы ш и узел Роли (Roles) и выполните команду Добавить роли (Add Roles).

4. На странице Перед началом работы (Before You Begin) щелкните Далее (Next).

5. На странице Выбор ролей сервера (Select Server Roles) установите флажок Службы федерации Active Directory (Active Directory Federation Services)

и щелкните Далее (Next).

6.Просмотрите сведения о роли и щелкните Далее (Next).

7. На странице Выбор служб ролей (Select Role Services) . установите фла - жок Служба федерации (Federation Service). Диспетчер сервера потребует добавить необходимые службы ролей и компоненты . Щ е л к н и т е кнопку Добавить необходимые службы ролей (Add Required Role Services), а затем Далее (Next).

8. На странице Выбор сертификата подлинности сервера для шифрования SSL (Choose A Server Authentication Certificate For SSL Encryption) выберите параметр Создать самозаверяющий сертификат д л я ш и ф р о в а н и я SSL (Create A Self-Signed Certificate For SSL Encryption) и щелкните Далее (Next).

Занятие 1 Концепция служб федерации Active Directory 878

В производственной среде сертификаты необходимо запросить в доверенном центре сертификации, чтобы все ваши системы могли совместно работать в Интернете.

9. На странице Выбор сертификата для подписи маркера (Choose A TokenSigning Certificate) выберите параметр Создать самозаверяющий сертификат д л я подписи маркера (Create A Self-Signed Token-Signing Certificate)

ищелкните Далее (Next).

10.На странице Выбор политики доверия (Select Trust Policy) выберите параметр Создать новую политику доверия (Create A New Trust Policy) и щелкните Далее (Next) .

За п о м н и т е путь сохранения этой политики доверия, поскольку данная

политика потребуется д л я работы связи федерации.

11. П р о с м о т р и т е сведения на странице веб-сервер (IIS) (Web Server (IIS))

ищелкните Далее (Next).

12.На странице Выбор служб ролей (Select Role Services) примите параметры

по у м о л ч а н и ю и щелкните Далее (Next).

13.На странице Подтвердите выбранные параметры (Confirm Installation Selections) просмотрите выбранные параметры и щелкните кнопку Установить (Install).

14. После з а в е р ш е н и я установки щелкните кнопку Закрыть (Close).

15.Повторите эту процедуру на машине SERVER03.

На компьютере S E R V E R 0 3 эта операция будет выполнена быстрее, поскольку S E R V E R 0 3 является корневым центром сертификации. Тем не менее у к а ж и т е те же параметры, что для SERVER07, и по возможности используйте самозаверяющие сертификаты.

ВНИМАНИЕ! Веб-сайт по умолчанию

После установки AD FS на обоих серверах федерации необходимо отконфигурировать в IIS сайт по умолчанию Default Web Site с использованием безопасности TLS/SSL, как описано на занятии 2.

Вы начали с м а ш и н ы S E R V E R07, поскольку этот компьютер не содержит никаких ролей и отображает все страницы установки в процессе инсталляции роли AD FS на новом сервере. Отметим, что поскольку на машине SERVER03 уже установлены некоторые роли сервера, процесс инсталляции AD FS на этом сервере выполняется быстрее.

У п р а ж н е н и е 3 . У с т а н о в к и прокси - серверов службы федерации

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

1. Запустите машины SERVER01, SERVER03, SERVER04, SERVER06, SER- V E R 0 7 и S E R V E R 0 8 . Войдите на машину SERVER08 как администратор домена.