Поиск на сайте: Расширенный поиск


Новые программы oszone.net Читать ленту новостей RSS
Hitman Pro - комплексное решение для удаления всевозможных шпионских и вредоносных программ с компьютера пользователя. У...
Программа предназначена для автоматизации работы компьютерных клубов. Внимательно следит за работой администраторов, вед...
Печать бланков Украина - программа для печати и выписки следующих документов: - договор, - счет-фактура, - расходная нак...
Aml Pages - это электронная записная книжка, оперативный блокнот на все случаи жизни, каталогизатор документов. Позволяе...
McAfee Stinger - это бесплатный, не требующий установки антивирус, для обнаружения и удаления с компьютера известных вир...
OSzone.net Microsoft Windows Server 2008 Администрирование Планирование инфраструктуры DNS для домена Active Directory вашей организации RSS

Планирование инфраструктуры DNS для домена Active Directory вашей организации

Текущий рейтинг: 4.5 (проголосовало 16)
 Посетителей: 10565 | Просмотров: 19324 (сегодня 0)  Шрифт: - +

Введение

*После того как для каждой модели леса будут выбраны домены Active Directory, вам необходимо спроектировать инфраструктуру DNS, так как каждое доменное имя является частью именного пространства DNS. Полагаю, что вам не нужно объяснять, что для локализации ресурсов в сети доменных служб Active Directory используется система доменных имен (Domain Name System, DNS), так как службы Active Directory не могут функционировать без стабильной конфигурации DNS. По сути, DNS является распределенной базой данных, которая предоставляет пространство имен и которая хранит все сведения, необходимые для того, чтобы любой пользователь вашей организации мог свободно подключаться к компьютерам и другим IP-сетям, используя понятные и легко запоминающиеся имена. Без ее стабильной инфраструктуры у доменных служб не будет возможности выполнять репликацию среди контроллеров домена в сети, а такие серверы, как Microsoft Exchange Server не смогут отправлять электронную почту. Поэтому можно сделать такой вывод, что проектирование инфраструктуры DNS является не менее важным этапом эффективного построения доменных служб в организации, причем, ключевым моментом является определение, где нужно локализовать домены Active Directory в текущем именном пространстве. Именно благодаря службе разрешения имен DNS, доменные службы Active Directory предоставляют для пользователей возможность без проблем находить все контроллеры доменов, а также контроллерам доменов обмениваться друг с другом сведениями. В большинстве случаев проект пространство имен для Active Directory разрабатывается проектировщиком службы каталогов совместно с хозяевами лесов и хозяином DNS. Сразу хотелось бы отметить, что большинство организаций имеют одно именное пространство как внутри организации Active Directory, так и в Интернете, и в итоге, в Интернете регистрируется лишь одно DNS-имя. Желательно, чтобы такие имена существовали отдельно от зарегистрированного доменного имени организации.

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

Некоторые нюансы, связанные с одним и с разными именными пространствами

Как я уже упомянул немного ранее, многие организации считают приемлемым оставлять одно доменное имя для сети организации Active Directory и в Интернете. В любом случае, в целях безопасности, независимо от того, какие именные пространства используются в вашей организации, ваш внутренний DNS сервер не должен быть доступным для внешних клиентов, так как он будет хранить записи всех ваших контроллеров доменов и записи всех клиентских компьютеров в сети. А в Интернете должны быть доступны только те записи ресурсов, к которым действительно необходим доступ из Интернета, например, ваши почтовые серверы или веб-серверы.

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

Важно понимать, что любое отличие доменных имен означает, что внутри организации используется другое именное пространство. Пример использования разных именных пространств внутри и вне организации обычно выглядит следующим образом: компанія Biopharmaceutics Ltd может использовать как внешнее именное пространство имя Biopharmaceutics.com, а такое имя как Biopharmaceutics.corp для внутреннего пространства имен. Чаще всего внутреннее именное пространство принято выбирать из соображений безопасности для предотвращения публикации внутреннего именного пространства в сети Интернет. Помимо всех преимуществ, у разных именных пространств есть один недостаток – вашей организации придётся регистрировать дополнительные DNS имена, что, правда, не обязательно, но крайне желательно, так как если другая организация зарегистрирует незанятое вами именное пространство, ваши пользователи больше не смогут локализовать ресурсы вашей интрасети в Интернете.

Проектирование нового именного пространства

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

Всем давно известно, что после того как компьютер с операционной системой Windows присоединяется к домену, он сам себе присваивает имя. Такое имя состоит из имени компьютера и DNS-имени домена Active Directory, которое называется полным доменным именем (FQDN). Но не все знают, что если у компьютера уже есть другое доменное имя DNS, которое было либо зарегистрировано службой DHCP-сервера или было статически введенное в DNS-зону, то полное доменное имя будет отличаться от зарегистрированного ранее имени и к такому имени далее можно будет подключаться по любому из этих двух имен.

Помимо использования DNS для локализации контроллеров доменов, систему Windows Server 2008 и Windows Server 2008 R2 вы можете интегрировать с DNS, тем самым разместив информацию зон DNS в хранилище данных доменных служб Active Directory. Другими словами, серверы DNS на контроллерах доменов могут хранить сведения о зонах не в текстовых файлах, а в доменных службах Active Directory. Интеграция зоны также значительно упрощает работу системного администратора тем, что вам не нужно отдельно настраивать топологию репликации DNS с использованием обычных передач зон, так как репликация всех сведений выполняется автоматически. Рассмотрим простой пример: если система Active Directory развертывается для корневого домена леса, то система DNS создает заполнители для зон прямого просмотра, зон обратного поиска, а также серверов условной пересылки. После этого DNS генерирует внутри зоны прямого просмотра две новые зоны, где первая такая зона служит контейнером для всего леса пространства имен, которое создается во время установки служб Active Directory, а вторая зона является зоной самого корневого домена. После этого, при создании доменного дерева в существующем лесу требуется процесс проведения делегирования в ручном режиме. Во время создания доменного дерева, мастеру не удается самостоятельно создать делегирование. По завершении процесса создания дочернего домена в существующем лесу, он автоматически создает делегирование в корневом домене высшего уровня, после чего сохраняет данные DNS дочернего раздела в разделе дочернего домена. Другими словами, от вас не требуется проводить каких-либо действий.

Таким образом, мы можем отметить для себя несколько преимуществ использования зон DNS, которые интегрированы с Active Directory:

  • Интегрированные зоны позволяют выполнять безопасные обновления. То есть, если зона DNS интегрирована в AD DS, то в ней вы можете настроить только использование безопасных обновлений, тем самым обеспечив возможность управления пользователями и компьютерами организации, которые могут обновлять записи ресурсов в Active Directory;
  • Процесс передачи зон заменяется репликацией доменных служб Active Directory. В связи с тем, что информация зон сохраняется не в текстовый файл, а в Active Directory, репликация таких данных выполняется посредствам стандартного процесса репликации доменных служб Active Directory. То есть, сама репликация выполняется на уровне атрибутов и касается лишь изменений данных зоны, тем самым экономя полосу пропускания и, соответственно, сжимая ваш трафик;
  • Интегрированные зоны обеспечивают дополнительную безопасность. Так как зоны DNS сохраняются непосредственно в Active Directory, для защиты объекта dnsZone в каталоге используются списки контроля доступа, обеспечивая гранулированный доступ к зоне;
  • Интегрированные зоны позволяют создавать для серверов DNS конфигурацию Multi-Master. С использованием зон, интегрированных в Active Directory, каждый DNS-сервер получает копию информации домена с правом записи, чтобы изменения данных зоны можно было вносить во всех организациях, что нельзя реализовать с серверами DNS без AD DS.

На следующей иллюстрации вы можете увидеть конфигурацию серверов DNS для организации без текущей инфраструктуры DNS:

*
Увеличить рисунок

Рис. 1. Конфигурация серверов DNS для организации без текущей инфраструктуры DNS

Проектирование инфраструктуры доменных имен в Active Directory с существующей инфраструктурой DNS

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

В первом случае, вы можете использовать текущую инфраструктуру, включая доменное имя для доменных служб Active Directory. То есть, при настройке серверов DNS, с целью разрешения имен Интернета обычно применяются серверы пересылки или конфигурируются DNS-серверы с использованием корневых подсказок. В свою очередь, серверы пересылки предусматривают высокий уровень безопасности, так как внутренний DNS-сервер можно настроить для пересылки на один или несколько внешних серверов DNS, а корневые подсказки гарантируют высокий уровень избыточности, так как они исключают вероятность сбоев. В этом случае вам потребуется небольшая реконфигурация существующей инфраструктуры DNS-серверов. Например, вы можете для компании Biopharmaceutics применить именное пространство Biopharmaceutics.corp, обеспечив данное именное пространство в качестве доменного имени служб Active Directory, а существующие ранее DNS серверы оставить без изменений.

Во втором случае, при проектировании инфраструктуры DNS для Active Directory, вы можете вынести домены AD DS дочерними доменами существующего внутреннего пространства имен, тем самым не затронув имеющуюся инфраструктуру. То есть, в случае существующего именного пространства Biopharmaceutics.com, вы можете создать дочерний домен corp. Biopharmaceutics.com.

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

На следующей иллюстрации вы можете увидеть конфигурацию серверов DNS для организации с существующей инфраструктурой DNS, методом настройки отдельного пространства имен внутри организации:

*
Увеличить рисунок

Рис. 2. Конфигурация серверов DNS для организации с существующей инфраструктурой DNS

Интеграция доменных служб Active Directory с текущей инфраструктурой DNS

Как вы уже догадались, в том случае, если в организации уже развёрнута инфраструктура DNS, то вам, в качестве владельца службы DNS доменных служб Active Directory, предстоит совместно с текущим владельцем службы DNS организации, интегрировать доменные службы DNS в существующую инфраструктуру. Например, если компания уже развернула доменные службы Active Directory самостоятельно, то, несмотря на то, что инфраструктура DNS уже может быть развернута и быть приспособленной для работы с Active Directory, перед вами может стоять задача исправления всех недочетов, которые мог допустить системный администратор данной организации. В другом случае, вам может попасться ситуация, которая довольно таки, к сожалению, распространена в нашей стране, когда организации уже имеют DNS сервера на серверах UNIX, а именно сервера BIND. В таком случае обычно компании предпочитают не удалять текущую инфраструктуру, а постепенно ее модернизировать до серверов Windows Sever 2008/2008 R2, это означает, что придется взаимодействовать с текущей инфраструктурой DNS. В большинстве случаев, для полноценной интеграции, вам нужно создать конфигурацию DNS-сервера и DNS-клиента. Также, в случае использования инфраструктуры BIND, у вас есть еще два способа интеграции. К первому способу относится использования серверов DNS не от Microsoft, у которых есть возможность создания зон DNS, требования которых удовлетворяет инфраструктуре Active Directory, а также поддерживают записи SRV и поддержку динамических обновлений с инкрементной передачей зон. Или вы можете развернуть одновременно сервер BIND с DNS-сервером в Windows Sever 2008 /2008 R2, задействовав в качестве основного сервера DNS или Windows сервер, или BIND (полностью по вашему усмотрению). Но не стоит забывать, что, развернув DNS-сервер под Window Server 2008/2008 R2 вы получите множество полезных дополнительных функций.

В процессе создания конфигурации DNS-сервера вам стоит выполнить следующие действия:

  1. Установить службу DNS-сервера на всех контроллерах доменов в созданном вами лесу, что обеспечит отказоустойчивость в том случае, если какой-то из серверов будет недоступным. Это упростит для вас среду управления, так как конфигурация на всех контроллерах доменов будет одинаковой, причем, контроллеры домена не будут зависеть от других серверов DNS при разрешении имен;
  2. Настроить контроллер корневого домена леса Active Directory так, чтобы он содержал зону DNS леса Active Directory;
  3. В случае необходимости, настроить все региональные контроллеры домена так, чтобы они содержали зоны DNS, соответствующие доменам контроллеров доменов Active Directory;
  4. Доменные службы Active Directory используют записи локаторов для того, чтобы партнеры репликации могли без проблем находить друг друга, а клиенты – находить серверы глобального каталога. Вам нужно настроить зоны, содержащие записи локатора Active Directory, а также репликацию на каждый DNS-сервер в лесу.

Для корректной настройки службы DNS на клиентских компьютерах, вам, как владельцу службы DNS доменных служб Active Directory, нужно указать схему именования компьютеров, а также способ поиска DNS-серверов для клиентов. Лучше всего использовать стандартную схему именования клиентских компьютеров, то есть полное доменное имя FQDN должно состоять из имени узла компьютера и имени домена AD. Также вам необходимо настроить клиентские компьютеры так, чтобы они указывали на все DNS-сервера, которые есть в сети.

Несвязанное пространство имен

Несвязанное пространство имен обычно возникает в том случае, когда у клиентских компьютеров, которые являются частью определенного домена, первичный DNS-суффикс не совпадает с DNS-именем домена Active Directory, членами которого они являются. Такое пространство имен значительно труднее администрировать, нежели связанное. Это в первую очередь состоит в том, что в несвязанном пространстве имен трудно устранять неполадки, так как в связанном пространстве имен первичный DNS-суффикс совпадает с именем домена Active Directory. Также, сетевые приложения, при создании которых предполагается, что пространство имен Active Directory идентично первичному суффиксу DNS для всех компьютеров, являющихся членами домена, могут работать ненадлежащим образом, что может стать огромной проблемой при работе приложений и служб. Поэтому, прежде чем разворачивать несвязанные пространства имен вам стоит протестировать все используемые организацией приложения на совместимость. Компьютеры, являющиеся членами домена, могут нормально функционировать в несвязанном пространстве имен. Они могут растрировать записи ресурса узла А или АААА, но в это время контроллеры домена будут продолжать регистрировать глобальные записи ресурсов и записи SRC в зоне DNS. Лучше всего использовать несвязанные пространства имен в двух случаях. Во-первых, если в лесу с несколькими доменами используется одно пространство имен, известное как DNS-зона. То есть, данный случай целесообразен при использовании региональных доменов. Во-вторых, целесообразно использовать несвязанное пространство имен в том случае, когда единый домен Active Directory разбит на несколько пространств имен DNS.

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

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

ПреимуществоНедостаток
Разделение управления пространством имен DNS и именем домена Active Directory, используя отличительные признаки.Для каждого домена AD необходимо создавать и управлять отдельной зоной DNS.
Структурирование пространства имен DNS с учетом структуры организации или географического местоположения, такого как континент, страна, город или здание.Изменение и управление атрибута, разрешающего членам домена использовать указанные первичные суффиксы DNS вручную.
Ручная настройка компьютеров с альтернативными первичными суффиксами DNS в групповой политике для оптимизации разрешения имен.
Соответствующая настройка порядка поиска суффиксов DNS для всех доменов Active Directory в лесу при необходимости нескольких первичных суффиксов DNS.
Необходимость тщательного тестирования приложений на совместимость с несвязанным пространством имен.
Автор: Дмитрий Буланов  •  Иcточник: dimanb.wordpress.com  •  Опубликована: 04.01.2011
Нашли ошибку в тексте? Сообщите о ней автору: выделите мышкой и нажмите CTRL + ENTER


Оценить статью:
Вверх
Комментарии посетителей RSS

Чтобы оставить комментарий, зарегистрируйтесь или войдите с учетной записью социальной сети.