Windows 2000 позволяет организациям интегрировать различные бизнес-подразделения в единую логическую структуру - лес Active Directory (AD). В Windows NT 4.0 такая возможность отсутствовала. Бизнес-процессы, которые не могут сосуществовать в домене Windows NT 4.0, допускают объединения в рамках организационных единиц (OU) или доменов AD. Но, как скажет любой администратор, который когда-либо пробовал объединить всю логическую архитектуру бизнеса в рамках одного леса, в бизнесе встречается множество ситуаций, не позволяющих идти только одним путем. Иногда условия ведения бизнеса или политические причины требуют организации отдельных лесов. Пользователи из этих лесов по-прежнему нуждаются в доступе к централизованным ресурсам. И, таким образом, администратор должен установить доверительные отношения между доменами центрального леса и доменами остальных лесов. Фактически в Windows 2000 используется тот же самый (и не очень удобный) механизм для установления доверительных отношений между доменами в различных лесах, что и в Windows NT 4.0. Но уже в операционной системе Windows Server 2003 было введено новое свойство доверительных отношений между лесами - Forest Trust, благодаря которому эта задача становится значительно проще.
Условия создания дополнительного леса
В контексте информационной безопасности домен ограничен, скорее, рамками единого администрирования, единой синхронизации, нежели рамками системы безопасности. Требуется совсем немного усилий, чтобы член группы Administrators, Domain Admins или Enterprise Admins смог получить доступ к любому компьютеру леса. Единственный способ по-настоящему изолировать тот или иной ресурс - поместить его в отдельный лес.Не следует отказываться от главной цели - свести всю архитектуру бизнеса в единый лес, но в реальной жизни эта цель может быть выражена несколько иначе: организация минимально необходимого количества лесов, причем введение дополнительного леса должно подчиняться строгим критериям принятия решения и соответствовать возможностям менеджмента. Стандарты принятия решения об организации леса представлены в статье Microsoft "Design Considerations for Delegation of Administration in Active Directory" (http://www.microsoft.com/windows2000/ techinfo/planning/activedirectory/addeladmin.asp). В ней же даются четкие указания о разграничении зон ответственности между OU, доменами и лесами, предлагается методика для определения принадлежности бизнес-подразделения организационной единице, домену или же самостоятельному лесу, отделенному от центрального.
В каких же случаях нужно делать выбор в пользу отдельного леса? Требования разделены по нескольким категориям. Самое известное требование организации обособленного леса заключается в необходимости обеспечить гарантированную автономию администрирования леса (требование типа "я вам не доверяю"). Другое основание создать отдельный бизнес-лес возникает в том случае, когда значительная часть бизнеса компании подчиняется более строгим правилам, нежели общий лес. Поскольку такая ситуация какое-то время будет иметь место, необходимо найти способ уживаться с ней. Другая ситуация связана с понятием схемы леса. Схема (т. е. описание структуры AD) размещена по всему лесу. Если ее приходится менять достаточно часто (например, когда проводится тестирование программ, взаимодействующих с AD), есть смысл выделить для этих целей отдельный лес с тем, чтобы схема AD компании менялась только в случае острой необходимости.
Информационная изоляция - еще одна важная причина иметь у себя отдельный лес. Например, правоохранительные органы должны хранить свои данные отдельно от других. Аналогично, информация о контрактах военных подрядчиков должна быть доступна только для "посвященных". В таких сферах, как банковское дело, ущерб от предоставления данных на всеобщее обозрение также очевиден.
Доверительные отношения внутри леса в Windows 2000
Протокол Kerberos автоматически устанавливает доверительные отношения между доменами в лесу Windows 2000. Важной особенностью реализации Kerberos является поддержка транзитивных доверительных отношений (transitive trusts). Если Domain A доверяет Domain B и Domain B доверяет Domain C, то и Domain A автоматически доверяет Domain C. Мнемоническое правило для запоминания только что приведенного утверждения - "друг моего друга - мой друг". Это свойство порождает концепцию деревьев доменов, когда распространение билета Kerberos автоматически приводило к установлению доверительных отношений между доменами одного леса. Двусторонние доверительные отношения Kerberos внутри леса также носят название внутренних доверительных отношений (internal trusts).
|
| Рисунок 1. Двусторонние доверительные отношения между лесами. |
Доверительные отношения между лесами в Windows 2000
Вне данного леса доверительные отношения выглядят более примитивно. В Windows 2000 протокол Kerberos не позволяет устанавливать доверительные отношения между несколькими лесами. Между отдельными доменами NT 4.0 и между доменами Windows 2000 в разных лесах доверительные отношения устанавливаются с помощью NT LAN Manager (NTLM). Эти доверительные отношения носят название внешних доверительных отношений (external trusts). Кроме того, существуют укороченные доверительные отношения (shortcut trust). Они используются в протоколе Kerberos для непосредственного связывания двух дочерних доменов в дереве доменов с целью повышения производительности обмена данными. Внешние доверительные отношения имеют те же ограничения, что и все остальные в NT 4.0: для внешнего доверительного отношения не поддерживаются специальные меры обеспечения безопасности, как это реализовано в Kerberos, и такие внешние доверительные отношения не обладают свойством транзитивности. В результате чего можно очень быстро оказаться в положении администратора сети NT 4.0, которому приходилось осуществлять поддержку настоящей паутины входящих и выходящих доверительных связей для каждого домена внутри каждого леса.Доверие лесов в Windows 2003
Forest Trust - это доверительная связь между двумя корневыми доменами двух разных лесов. На Рисунке 1 показаны двусторонние внутренние доверительные отношения в лесах Forest A и Forest B и двусторонние связи Forest Trust между Forest A и Forest B. С помощью доверительных отношений между лесами можно "привязать" взаимосвязанные леса один к другому и сформировать то, что получило название федерации или альянса. Эта федерация или альянс лесов представляет собой простую и легко обслуживаемую структуру, масштабируемость которой выходит далеко за рамки возможностей протокола NTLM. Поскольку в данном случае речь уже идет об использовании Kerberos, а не NTLM, доверительные отношения транзитивны. Например, если Forest A доверяет Forest B, то и все домены Forest A доверяют всем доменам Forest B. Вместе с тем, надо отметить, что эти доверительные отношения не являются сквозными, т.е. не распространяются через структуру леса: если Forest A доверяет Forest B и Forest B доверяет Forest C, то отсюда еще не следует, что Forest A автоматически станет доверять Forest C. Те же правила используются при установлении доверительных отношений с помощью NTLM между доменами NT 4.0, только объектом масштабирования становится уже не домен, а лес доменов. Как и в случае с доверительными отношениями NTLM, можно устанавливать одно- и двунаправленные отношения доверия между лесами.Преимущества доверительных отношений между лесами
|
| Рисунок 2. Лес учетных записей. |
Хотя между различными лесами можно создать также и внешние доверительные отношения, использование основанных на протоколе Kerberos доверительных отношений между лесами кардинально сокращает число доверительных связей, необходимых для обмена данными между лесами. Для подсчета общего числа внешних отношений доверия для поддержки доверительных отношений между всеми доменами в двух лесах нужно воспользоваться следующей формулой:
(Общее число внешних отношений доверия) = (одно- или двусторонняя связь) * (Число доменов в лесу Forest A) * (Число доменов в лесу Forest B).
Предположим, например, что в компании имеется лес Development (DEV) в составе трех доменов и лес Production (PROD) в составе четырех доменов, и требуется установить двусторонние доверительные отношения между всеми доменами обоих лесов. Потребуется создать и поддерживать в дальнейшем работу 24 доверительных связей (2*3*4). Некоторое неудобство очевидно, но нельзя сказать, что это катастрофа. Однако если через какое-то время к описанной топологии придется добавить лес Integration (INT), состоящий из четырех доменов, все значительно усложнится. Вместо одного отношения доверия между двумя лесами потребуется создать три: DEV - PROD, DEV - INT и PROD -INT. При этом общее число доверительных связей достигнет 80.
Важный элемент стратегии, который достигается с помощью доверительных отношений между лесами, - возможность реализовать лес учетных записей. Как видно из схемы, представленной на Рисунке 2, по сути это не что иное, как версия взаимодействия домена учетных записей и ресурсных доменов NT 4.0, только в увеличенном масштабе. Приступая к созданию леса учетных записей, сначала нужно убедиться, что все основные (не тестовые) учетные записи настроены в главном лесу. Затем следует установить односторонние доверительные связи от всех остальных лесов (лесов ресурсов) к главному. Дополнительная информация о создании односторонних доверительных отношений приведена на врезке "Создание простой односторонней связи". Пользователи могут использовать свои основные учетные записи для регистрации в любом лесу федерации. Более того, администратор даже может делегировать право создания доверительных связей пользователям, не входящим в состав группы Enterprise Admins.
Читатель может спросить, почему доверительные отношения между лесами в операционной системе Windows 2003 могут содержать другой лес, тогда как внешние доверительные отношения Windows 2000 этого не допускают. В Windows 2003 объект Trusted Domain Object (TDO) является основным для получения информации об отношении доверия как для внешних отношений доверия, так и для отношений между лесами. В TDO имеется дополнительный атрибут, используемый доверительными отношениями между лесами, называемый Forest Trust Information. Этот атрибут несет информацию обо всех доменах в удаленном лесу, об именах дерева и обо всех альтернативных суффиксах имен. Все эти данные необходимы при маршрутизации аутентификации и обращениях в удаленный лес. Реально данные хранятся в глобальном каталоге Global Catalog (GC), поэтому любой контроллер домена (DC) может обратиться за нужной информацией.
Настройка доверительных отношений между лесами в Windows 2003
Для того чтобы построить Forest Trust, сначала нужно убедиться, что по обе стороны доверительного отношения между лесами реализован функциональный уровень леса Windows 2003. На каждом контроллере домена в обоих лесах обязательно должны работать операционные системы Windows 2003, и каждый домен должен соответствовать функциональному уровню домена Windows 2003.
Далее, корневые домены в обоих лесах должны "видеть" друг друга через DNS. Если речь идет о корпоративной распределенной сети и оба леса интегрированы в DNS компании, скорее всего, корневые домены всех лесов взаимно доступны. Чтобы проверить это, нужно открыть на сервере в любом лесу окно командной строки и набрать команду Nslookup. Следует ввести
set type=ns
и затем - полностью определенное имя, Fully Qualified Domain Name (например, forestb.mycompany.com), корневого домена соседнего леса. Если сервер сможет разрешить введенное имя FQDN, утилита Nslookup вернет соответствующий список контроллеров домена.
Если в существующей конфигурации DNS невозможно найти соседние леса, необходимо на данном DNS настроить дополнительную пересылку запросов на все серверы DNS в каждом лесу. Следует добавить одну или несколько схем пересылки запросов от одного корневого домена к другому, и наоборот. Сервер пересылки сообщает локальному серверу DNS, что при получении запроса к определенному домену тот должен переслать полученное обращение на указанный адрес IP. Предположим, например, что нужно объединить ForestA.com и ForestB.com связью Forest Trust. Находясь в Microsoft Management Console (MMC), требуется открыть контекстное меню сервера DNS, обслуживающего лес Forest A, и выбрать Properties. Затем следует перейти на вкладку Forwarders и указать адреса IP серверов DNS, на которые будут пересылаться запросы при обращении к Forest B (см. Экран 1). Описанную процедуру необходимо повторить для пересылки запросов от Forest B к Forest A.
|
| Экран 1. Настройка сервера пересылки запросов. |
Нужно помнить, что при использовании серверов для пересылки запросов к лесу (следовательно, речь идет уже об организации доверительных отношений между несколькими лесами) требуется указывать адреса IP вручную. Если любой из этих адресов изменится, а администратор забудет должным образом подкорректировать таблицу пересылки запросов (на всех серверах DNS), в установленных ранее доверительных отношениях могут начаться сбои. После того как имена обоих лесов будут успешно разрешены, для установки соответствующего типа отношений доверия используется консоль Active Directory Domains and Trusts и мастер New Trust Wizard. Теперь мы шаг за шагом рассмотрим случай установления двусторонних доверительных отношений между лесами.
В меню Administrative Tools следует выбрать пункт Active Directory Domains and Trusts или в командной строке ввести
domain.msc
Затем нужно открыть контекстное меню корневого домена, выбрать Properties и обратиться к схеме Trusts. Для запуска мастера установки новых отношений доверия необходимо выбрать New Trusts.
Программа New Trust Wizard впервые появилась в Windows 2003. С ее помощью можно выбрать нужный тип отношений доверия, задать любой из четырех возможных оконечных объектов - систему Windows 2003 или домен Windows 2000, домен NT 4.0, зону Kerberos 5.0 и, наконец, соседний лес. Всегда под рукой справочная служба New Trust Wizard, она позволяет получить дополнительную информацию о доверительных отношениях, функциональных уровнях, об именах User Principal Name (UPN) - пользователях или процессах, имеющих учетную запись в данной среде.
Хотя для выполнения задач, связанных с доверием, используется специально разработанный мастер, необходимо соблюдать осторожность при установке доверительных отношений и тщательно просмотреть все описания на последнем экране, прежде чем дать согласие инициировать установку отношений доверия. При установке доверительных отношений существует очень много различных возможностей, и мастер не рекомендует устанавливать поверх существующего типа отношений доверия связь другого типа. Если ошибка все же произошла, создание доверительных отношений между лесами становится невозможным, и часто бывает, что единственный выход - установление не отношений типа Forest Trust, а всего-навсего внешних доверительных отношений. Например, если администратор по ошибке выбрал дочерний, а не корневой домен, установка доверительных отношений между лесами невозможна - недоступен для выбора сам режим, однако понять, что к чему, совсем не просто.
Первое, что нужно сделать при работе с New Trust Wizard, - указать DNS- или NetBIOS-имя леса, с которым необходимо установить доверительные отношения. Если на этом и на нескольких последующих этапах все будет сделано правильно, появится диалоговое окно с предложением выбрать либо External trust, либо Forest trust (см. Экран 2). Если вариант доверительных отношений между лесами не появляется, следует вернуться обратно на первую страницу и попробовать найти ошибку, обратившись к справочной информации.
|
| Экран 2. Выбор типа отношений доверия. |
В нашем примере мы будем устанавливать двусторонние доверительные отношения. Как показано на Экране 3, New Trust Wizard позволяет создать две односторонние доверительные связи, с помощью которых реализуется двустороннее отношение доверия (конечно, при условии, что в соседнем лесу администратор также обладает соответствующими привилегиями) - и все это не покидая программу установки.
|
| Экран 3. Реализация двусторонних отношений доверия. |
Следующие два диалоговых окна определяют, нужно ли администратору, чтобы пользователи из соседнего леса автоматически проходили аутентификацию при обращении к ресурсам локального леса, и наоборот. Если выбрать Allow authentication only for selected resources in the local forest, как показано на Экране 4, операционная система Windows 2003 не будет автоматически добавлять Authenticated User SID леса ресурсов к маркеру пользователя леса учетных записей; придется предоставлять доступ к ресурсам на индивидуальной основе. Такой подход называют селективной аутентификацией (selective authentication). Естественно, это более безопасная методика; аутентификация выполняется как для пользователей ресурсного леса, так и для пользователей леса учетных записей. При этом, однако, возрастает нагрузка на администратора системы, поскольку он должен явным образом предоставить доступ к каждому домену и к каждому серверу, к которым могут обратиться пользователи из соседнего леса.
|
| Экран 4. Селективная аутентификация. |
Окно Trust Selections Complete позволяет просмотреть все настройки, перед тем как инициировать процедуру создания доверительных отношений. То же самое окно, Trust Selections Complete, появится на экране и после установления отношений доверия. На завершающем этапе работы мастер предоставляет администратору системы еще одну полезную возможность. Так как к этому моменту администратор уже должен был обеспечить возможность удаленного доступа к соседнему лесу, все дополнительные шаги по установлению отношений доверия могут быть инициированы без необходимости всякий раз подтверждать свои намерения. После того как доверительные отношения между лесами успешно созданы и мастер завершил свою работу, на схеме свойств Trusts рядом с типом отношений доверия появится надпись forest, а не child или external.
Хотя создание доверительных отношений между лесами представляется достаточно очевидным процессом, последствия ошибок, привнесенных в установку доверительных отношений, могут оказаться очень серьезными, особенно если работа пользователей протекает в нескольких лесах. Необходимо соблюдать осторожность при создании доверительных отношений. Прежде чем приступать к работе, нужно изучить примеры успешной реализации этой задачи.
Ограничения доверительных отношений между лесами
Нельзя сказать, что идея доверительных отношений между лесами так уж прозрачна для обычных пользователей. Когда пользователь регистрируется на станции, входящей в один лес, а его учетная запись заведена в другом лесу, в окне регистрации в списке доступных доменов пользователь не увидит "родного" домена. В этом случае он должен будет указать полное имя UPN (например, jimbob@bigtex.net). Разработчики Microsoft были вынуждены пойти на это, так как в условиях Multiforest возможен конфликт имен NetBIOS. Предположим, например, что forest1.bigtex.net и forest2.bigtex.net находятся в одной и той же географической зоне. Хотя имена FQDN (namerica.forest1.bigtex.net и namerica.forest2.bigtex.net) уникальны, может получиться так, что, если тот и другой лес не используют одно и то же пространство имен WINS, оба они могут оказаться в составе доменов с именем NetBIOS, скажем, NAMERICA. Кроме того, при попытке пользователя из леса ресурсов добавить из соседнего леса пользователей (или их группы) к ресурсам своего леса (cross-forest access), окажется, что соответствующие списки учетных записей недоступны (если только пользователь леса ресурсов не зарегистрирован на станции Windows 2003 Server или Windows XP Service Pack 2 (SP2)). Итак, пользователь леса должен указывать UPN. На Экране 5 показан список доступа ACL, для ресурса в лесу Forest A, к которому добавляется новый пользователь из леса Forest B. При этом в элементе контроля доступа ACE вместо синтаксиса domainaccount используется UPN.
|
| Экран 5. Организация «сквозного» доступа и использование UPN. |
Конфликты имен в лесу - другая важная причина для использования UPN. По умолчанию формат UPN следующий: account@FQDN. Например, если Jim Bob имеет учетную запись в дочернем домене lubbock.bigtex.net, то его UPN по умолчанию - jimbob@lubbock.bigtex.net. Кроме того, можно использовать корневой домен для выбора UPN с именем jimbob@bigtex.net. Во многих компаниях UPN корневого домена используется так, чтобы UPN соответствовало адресу электронной почты пользователя. Такая стратегия работает в тех случаях, когда имеется только один лес с учетными записями пользователей. Что, однако, произойдет, если учетные записи пользователей содержатся в нескольких лесах? Каждый из них в рамках данной компании имеет почтовый адрес bigtex.net, но после того, как один лес задействует упомянутый суффикс UPN, другой уже не сможет этого сделать. С одной стороны, нужно выбирать уникальные, непересекающиеся суффиксы UPN для своих пользователей (например, f1.bigtex.net, f2.bigtex.net). С другой - для электронной почты может использоваться bigtex.net.
Доверительные отношения между лесами - важное свойство Windows 2003. Благодаря этому свойству устранено ограничение Windows 2000, когда поддержка работы при наличии нескольких лесов оказывалась на практике очень непростой задачей. Для тех компаний, которым необходима тесная интеграция, только одна эта возможность может оправдать затраты на перевод систем Windows 2000 на платформу Windows 2003.
Шон Дьюби- редактор журнала Windows & .NET Magazine, старший системный инженер компании Intel, специализирующийся на проектировании корпоративных сетей на базе Windows 2000. С ним можно связаться по электронной почте по адресу: spdeuby@winnetmag.com.
Создание простой односторонней связи
Одной из наиболее общих задач, возлагаемых на системного администратора и, следовательно, требующих полномочий учетной записи Administrator, является создание односторонних доверительных отношений между доменом учетных записей и доменом ресурсов. Используя доменную топологию, основанную на доверительных отношениях, администратор централизованно размещает учетные записи пользователей на серверах доверенного домена (trusted domain) и предоставляет пользователям доступ к ресурсам серверов в составе доверяющих ресурсных доменов (trusting domain). В Windows Server 2003 появляется новая группа - Incoming Forest Trust Builders. Члены этой группы могут создавать для локального леса входящие односторонние доверительные отношения, не обладая при этом правами администратора системы. Речь идет о делегировании права запуска процедуры создания входящих отношений доверия, и это может быть полезно в том случае, когда в компании требуется разгрузить основных администраторов системы и освободить их от необходимости устанавливать доверительные отношения.