| Новые программы oszone.net |  |
Введение
Проектирование инфраструктуры доменных имен в 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 для организации без текущей инфраструктуры 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-сервера вам стоит выполнить следующие действия:
Для корректной настройки службы 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, вам необходимо спроектировать инфраструктуру 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-имя. Желательно, чтобы такие имена существовали отдельно от зарегистрированного доменного имени организации.
