Логическая структура домена: блок-схема

Логическим контейнером доменов Windows Server 2003 служит лес. Леса образованы из деревьев, имеющих корни; в свою очередь, деревья домена образуют сеть Windows Server 2003.

После создания корня домена у вас практически не было шанса изменить его параметры при использовании Windows 2000; к счастью, Windows Server 2003 обладает средством переимено­вания доменов. Кроме того, необходимо помнить, что чем глубже пространство имен, тем оно более гибкое, и тем легче перемещать объекты между доменами и деревьями доменов. Однако вряд ли вам захочется удалять или переименовывать домены, которые несут огромную нагрузку. Поэтому постарайтесь тщательно обработать всю полученную в результате анализа предпри­ятии информацию и правильно спланировать структуру домена. Как мы неоднократно говорили в главе 8, "Планирование Active Directory", протестируйте все, что можно.

Домен верхнего уровня

Создание сети Windows Server 2003 требует обязательного создания корневого домена, или, как его еще называют, домена верхнего уровня. Определение имени корня и выполняе­мой им роли приводит в замешательство многих людей: четко определенных правил, приме­нимых к любой компании, не существует.

Корневой домен может выполнять две основные роли: служить контейнером объектов или, аналогично корневому домену Internet, выступать в качестве точки входа каталога.

Определение имени корневого домена

Первым решением, которое вам придется принять, будет выбор имени корневого домена Windows Server 2003. Имя корневого домена—- это нечто большее, чем идентификатор. На самом деле это основа корпоративного пространства имен Active Directory. Ваше пред­приятие, возможно, уже имеет зарегистрированное в соответствующей организации домен­ное имя, а значит, и существующее пространство имен.

В нашем примере мы зарегистрировали для города Миллениум-Сити доменное имя mcity.org в организации InterNIC (Network Solutions, Inc.). Вопрос не в том, каким образом обеспечить сосуществование пространств имен интрасети вашей организации и Internet, а в том, как их объединить.

Существуют две возможности:

• ограничить применение общедоступного доменного имени только внешней средой(в этом случае за его разрешение будет отвечать DNS-сервер поставщика услуг Internet);

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

Рассмотрим каждую из них более подробно.

Если доменное имя предприятия находится на "ветке" . com или . org системы DNS, оно становится общедоступным Internet-именем и может использоваться как отправная точка при разрешении доменных имен Internet-ресурсов предприятия, таких как Web-сервер или сервер электронной почты. Так, запрос доменного имени mcity.org в конечном итоге приведет клиента к серверу DNS, который сможет разрешить имена компьютеров, относящихся к до­мену MCITY. Серверы DNS, регулярно обслуживающие запросы на разрешение имени mcity. org, занесут необходимые сведения в кэш.

Стоит ли использовать общедоступное имя домена в качестве имени корневого домена в логической структуре предприятия? В рассматриваемом нами примере мы не видим причин, по которым от этого нужно было бы отказываться. Тем не менее по целому ряду причин ре­зультаты исследования предприятия могут привести к противоположному выводу. Рассмот­рим все "за" и "против".

Ниже перечислены причины, по которым внешнее и внутреннее пространство имен DNS I предприятия должны совпадать.

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

• В Internet необходимо защищать только одно пространство имен.

• Необходимо администрировать только одно пространство имен.

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

• Домены будут существовать независимо друг от друга, что позволит отделять внешние ресурсы от внутренних. Корпоративная интрасеть будет более защищенной, что, тем не менее, не избавит от необходимости использования хорошего брандмауэра.

• Компания может легко изменить направление своей деятельности и даже название.

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

• Легче настраивать работу таких ТСР/IР-приложений, как Web-обозреватели и FTP- клиенты. Не нужно следить за тем, чтобы клиенты, одновременно подключенные к интрасети и Internet, получали доступ к необходимым ресурсам.

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

Оказывается, проблемы суффиксов доменов можно избежать. Клиенты Windows Server 2003 имеют возможность сохранять в учетной записи более одного имени UPN, как показано на рис. 9.3. Это достигается путем присвоения домену дополнительных суффиксов, что следует делать очень осторожно, дабы избежать конфликтов с учетными записями поль­зователей из других доменов. Клиенты нижнего уровня вынуждены использовать назначен­ное домену имя NetBIOS. Для того чтобы добавить новый суффикс домена, откройте консоль Active Directory

Domains and Trusts (Active Directory— домены и доверие), после чего щелкните правой кнопкой мыши на узле Active Directory Domains and Trusts и выполните команду контекстного меню Properties (Свойства). Дополнительные суффиксы домена пере­числены на вкладке UPN Suffixes (Суффиксы UPN).

Мы также не верим в то, что при использовании одного пространства имен интрасеть окажется более защищенной. Какое бы имя ни было выбрано для корневого домена Active Di­rectory, контроллер домена все равно будет скрыт за брандмауэром. Кроме того, ему будет назначен ГР-адрес, принадлежащий частной сети и скрытый от посторонних глаз с помощью механизма преобразования сетевых адресов и т.п. (см. главу 15, "Сетевые возможности Windows Server 2003"). Другими словами, ни один из ресурсов интрасети нельзя будет обна­ружить из Internet.

Вероятно, для защиты ресурсов интрасети вы примените брандмауэры и преобразование сетевых адресов. И тем не менее, несмотря на любые меры защиты (и уж тем более незави­симо от того, будут ли совпадать внутреннее и внешнее пространство имен DNS) ваша сеть все равно будет подвергаться атакам различных типов. В настоящее время большинство ком­паний уже развернули зеркальные сайты по обе стороны брандмауэра.

Вторая причина отказа от использования общедоступного имени домена заключается в том, что имя компании может измениться (к примеру, компания может быть разделена или поглощена более крупной компанией). К сожалению, провести соответствующее измене­ние имени корневого домена практически невозможно. И если системный администратор не будет заранее посвящен в планы руководства, он может оказаться захваченным врас­плох. Именно по этой причине мы призываем уделить анализу предприятия как можно больше времени.

Рис. 9.З. Изменение стандартного суффикса домена

Необходимо также помнить, что суффикс UPN (User Principal Name— основное имя пользователя) никоим образом не связан с именем корневого или любого другого домена. Ес­ли имя компании или общедоступного домена неожиданно изменится, суффикс UPN может быть скорректирован в любое время. При этом лежащие в его основе глобальные уникальные идентификаторы (GUID) остаются неизменными даже в том случае, когда объекты переме­щаются в другую область дерева домена или "клонируются" с помощью соответствующих инструментальных средств.

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

В настоящее время практически невозможно зарегистрировать доменное имя, которое бы полностью совпадало с именем самой компании. К примеру, ваша компания называется Rain­bow. Весьма вероятно, что в мире существует целый ряд других компаний, называющихся точно так же или включающих в свое называние слово Rainbow. Зарегистрировать доменное имя rainbow, com сможет только одна из этих компаний, остальным же придется довольст­воваться более или менее подходящими именами.

Для нашего примера мы зарегистрировали имя mcity.org (приблизительно через неде­лю у нас уже хотели его купить). Следует отметить, что в данном конкретном случае это имя вряд ли изменится, так как изменение имени города очень маловероятно.

Возвращаясь к суффиксам UPN, следует отметить, что они обязательно должны совпадать с именем общедоступного домена для того, чтобы внутренние и внешние адреса электронной почты были одинаковыми. Если имя общедоступного домена изменится (а значит, изменятся и суффиксы адресов электронной почты), вы всегда сможете назначить учетным записям пользователей другой суффикс UPN (рис. 9.4).