Материал: Книга Active directory

Легенда Доверие лесов

Рис. 17-1. Реализация доверительных связей между множеством лесов может представлять очень сложную задачу

Использование доверительных о т н о ш е н и й не всегда я в л я е т с я о п т и м а л ь н ы м методом реализации партнерства.

Назначение брандмауэра

два уровня защиты. Сам периметр обеспечивает м н о ж е с т в о т а к и х сервисов, к а к службы сертификации Active Directory ( A c t i v e D i r e c t o r y C e r t i f i c a t e Services,

25 —( .SMTP

Ретрансляция UgJ^J SMTP

Рис. 17-2. Основой безопасного периметра является набор безопасных брандмауэров

Службы федерации Active Directory

м и р ( р и с . 17-3), а н а л о г и ч н ы е д о в е р и ю лесов или явному доверию, но не через т р а д и ц и о н н ы е T C P / I P - п о р т ы LDAP, а через порты HTTP . В частности, исполь- з у е т с я п о р т 443, п о с к о л ь к у все д о в е р и т е л ь н ы е к о м м у н и к а ц и и AD FS являются б е з о п а с н ы м и и з а ш и ф р о в а н н ы м и и, т а к и м образом, задействуют технологию AD CS д л я п р е д о с т а в л е н и я с е р т и ф и к а т о в каждому серверу в структуре AD FS,

Легенда

Интеграция технологий Active Directory Потенциальные связи

Рис. 17-3. Службы AD FS расширяют полномочия внутреннего каталога AD DS

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

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

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

Отметим, что для создания среды AD FS можно использовать меньше компьютеров, как описано в руководстве «Microsoft Step-by-Step Guide for AD FS»

A82F-4428-9BBD-A103B9F27654&displaylang-en, однако AD FS не рекомендует-

ся устанавливать иа контроллере домена AD DS, поэтому такой тип установки не описан в данной книге.

История из жизни

Даниэль Реет и Нельсон Реет

В 2005 году одному из наших клиентов, солидной организации в сфере здравоохранения, потребовалось решение для проверю! подлинности. Необходимо было создать систему, объединяющую докторов, фармацевтов, работников социальных служб, больниц, частных клиник и т. д. в едином интегрированном решении идентификации и доступа IDA (Identity and Access). Поскольку для проверки подлинности и сетевого доступа большинство этих организаций использовали внутренние каталоги Active Directory, за основу были взяты технологии Windows.

Цель заключалась в том, чтобы все члены системы могли проходить проверку подлинности внутри нее. Это была довольно непростая задача. Хотя многие крупные партнеры содержали собственные внутренние леса Active Directory, большинство мелких партнеров не располагали такими возможностями. Например, нельзя было объединить аптеки для единой проверки подлинности, а частные клиники и врачи вообще не использовали такую технологию.

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

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

Версии Windows Server 2008 тогда еще не было, и мы порекомендовали Windows Server 2003 R2, поскольку в этом выпуске появился исходный релиз служб федерации Microsoft. Кроме того, два года назад корпорация Microsoft разработала технологию ADAM (Active Directory Application Mode), и этот набор казался идеальным для интеграции трех технологий. Мы предложили следующее:

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

•разрешить каждому партнеру управлять своими внутренними службами каталогов без вмешательства извне;