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

Перечислим ситуации когда создание нескольких доменов необходимо и оправдано:

• В случае когда необходимо привязать к различные политики безопасности. Так как политики безопасности могут содержать различные требования то мы вынуждены создать дополнительные домены и к каждому из них привязать необходимую политику, или более жесткую или скажем более либеральную.
• Обеспечению соответствию административным требованиям, связными с правовыми соображениями или конфиденциальностью. Одним словом, когда не надо всех админов пускать, или админы не доверяют друг другу по той или иной причине. 
• При большом трафике репликации в целях его оптимизации проводят деление доменов или добавление доменов или изначально зная что трафик будет большим и сразу создают больше доменов в зависимости от реальной ситуации.
• При наличие в сети старых доменов которых нужно сохранить под управлением Windows NT.
• Необходимость создания отдельного пространства имен. 

Если из всех перечисленных ситуаций, ни одна к вам он не относится, то вам повезло и у вас будет один домен (может быть...).

Но давайте рассмотрим некий алгоритм деления вашей сети на домены. Допустим вы новый админ и вы решили установить Windows Server  и поднять Active Directory. Какие шаги вы должны при этом сделать, что бы принять решение о необходимости деления на домены, их количество, и прочие необходимые работы.

Количество доменов.

Итак:

Шаг номер один. Вы проводите ревизию своей сети  (пусть сеть Ethernet). Составляйте физическую и логическую топологию сети. Под физической топологией имеется в виду сами провода и скорость передачи линий, тип связи. Под логической топологией деление физической сети на подсети (сегменты) и прочие. Хорошо бы сделать мониторинг сети, и посмотреть на загруженность сети, объем трафика в зависимости от протоколов и сетевых программных приложений,  и я бы с вами обсудил эту тему но это отдельная целая и длинная статья касающаяся больше сетевых технологий чем Active Directory, думаю если буду свободен позже и это обсудим в отдельной статье касающейся непосредственно сети, а пока это оставим, что бы вас не запутать совсем.

Итак,  Вы создаете план сети, на бумаге указывая на каждом сегменте сети:

• количество пользователей
• скорость передачи линии.
• Надежность связи
• Все основные используемые протоколы.
• Программные приложения производящий обмен данными по сети.
• Тип связи (выделенные, коммутируемые).
• Загрузку каждого сегмента.  

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

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

Шаг второй. После того как участки у нас обозначились, посмотрите на ваш план и соедините или разграничите эти участки на области,  разместите в каждой области по одному контролеру домена. На этом этапе о количестве контролеров пока не задумываемся. К примеру, берем  область  на плане с потрясающей скоростью и хорошей надежностью. Вот туда и лепим один контроллер на плане ( допустим это наш главный офис).  А вот на этом участке и канал хороший по скорости, надежность связи неплохая, но трафик большой, то может, стоит, задумается и поделить сеть на логические подсети (сегменты), что бы снизить служебный трафик и в любом случае выделяем эти участки в отдельную область или области (если таких участков много) и ставим туда же по контроллеру.  Если у нас допустим филиал, и канал связи слабый, ненадежный или перегружен то эти области так же отмечаем на плане и туда так же по контроллеру. Но не отмечайте филиалы, в которых, к примеру, два компа, так как тогда вам нужно будет туда поставить контроллер домена, а это бабки, и шефам вряд - ли понравится ваше абсолютно верное техническое решение. Короче вы исходите из того – если связь хорошая и сеть не перегружена, то это одна область и туда помещаем контроллер домена (к примеру это наш центральный офис). Если больше никаких проблемных участков нет,  и один участок помещается в одну область, то вам повезло.  Если между участками плохая связь или канал ненадежный или перегружен, то эти участки группируем  (или делим) отдельно в области (допустим связь между филиалами). Если в изучили все предыдущие темы на сайте а особенно статью описывающие сайты, то вам на ум должно прийти что данные области есть и будущие прототипы или претенденты на наши сайты. То есть, проводя по плану что у нас нарисован на бумаге, такие разбиения которые мы описали тут мы создаем и план сайтов. Но к плану сайтов еще вернемся ниже.   

Шаг третий. Теперь после того как мы определили где у нас будут, размещается контроллеры доменов в нашей сети, привяжем их к домену. Первое что надо, это проследить путь регистрации пользователя в сети. Обязательно учтите тот факт, что при регистрации пользователя в сети контроллер домена обращается к глобальному каталогу (GC), так что если глобальный каталог расположен далеко и на медленном или ненадежном, или перегруженном сегменте то это плохо. Учтите это.  На основе этих данных вы и будете принимать решение сколько контролеров домена у вас будут в домене. Так же необходимо посмотреть в сети путь прохождения репликации между контроллерами.  Если допустим,  мы решили что у нас будет один домен, а он получается очень большим, то тогда и трафик репликации, не считая весь сетевой трафик, будет большим. В таком случае следует подумать может быть стоит поделить данный домен на два домена поменьше и тогда мы как бы локализируем репликацию в переделах домена а не пускаем ее в всю сеть. От этого выигрывает весь сетевой трафик.

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

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

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

Выбор корневого домена.

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

К определению основного контролера домена леса надо подходить со всей возможной внимательностью. Дело в том что переназначение другого домена на эту роль, довольно неблагодарная задача о которой и говорить не буду. То же самое относится и к нашему специализированному домену. То есть мы берем и создаем такой специальный корневой домен. В этом специальном корневом домене мы храним только учетные записи администраторов разного уровня, то есть учетные записи администраторов предприятия, администраторов схемы, администраторов домена, и какие там еще есть по умолчанию при создании домена, или скажем при поднятии Active Directory. Об этих учетных записей нам еще предстоит поговорить далее более детально. К корневому домену мы не привязываем никакие подразделения. Это делается из того что подразделения могут меняется, или вообще могут быть удалены, а вот корневой домен леса всегда необходим, то есть "живее всех живых" с его учетными административными записями созданные по умолчанию. Лучше всего размещать такой корневой домен там где находится руководство или поближе к нему. Дело в том что такой корневой специализированный домен позволяет жестко ограничивать круг лиц, а так же контролировать их, администрирующих (управляющих, разрешающих) правами на остальные административные группы которые у нас есть.  еще одно преимущество в его доступности так как он не связан с жестко со структурой предприятия или фирмы, а так же генерирует малый объем трафика репликации.  

После того как мы определились с корневым доменом следует операция определении доменной иерархии или то же самое можно сказать как - объединение доменов в деревья. 

Определение иерархии доменов (или объединение доменов в деревья).

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

Если мы планируем дальше развиться и создать лес с деревьями, то имя единственного пока, или лучше скажу первого  созданного домена  и будет основой для всех дочерних доменов в дереве.Думаю это понятно, если нет смотрите тут. Имена доменов в дереве смежные, то есть если у нас домен родитель rk.com, то дочерний домен скажем так первого уровня по отношению к родителю будет к примеру antarctida.rk.com или еще один домен того же уровня по отношению у родителю africa.rk.com. Дочерний домен от  antarctida.rk.com, будет к примеру kontora.antarctida.rk.com, а так же в иерархии будет на уровень ниже чем его родитель по отношению к прародителю (или скажем дедушке, под этим я имею ввиду основной домен родитель иерархии домен rk.com).

Если в лесу несколько деревьев то  их корни связаны напрямую  с корневым доменом леса. Мы еще к этому вернемся.

Естественно что имена доменов разных деревьев являются не смежными.  Если у нас родитель иерархии первого домена в лесу допустим домен rk.com  то все имена иерархии доменов будут иметь в имени атрибуты родителей то иерархия второго допустим дерева xu.com будут иметь в имени атрибуты этого родителя и всех остальных родителей по иерархии вниз. 

Главное что нужно учитывать при строении дерева это то что если вы потом захотите удалить или переместить в другое дерево промежуточный иерархический домен, сделать это можно, только если мы удалим домен и все нижележащие дочерние домены. Так что, если вы это предполагаете, поместите такой домен в отдельное дерево.

Ладно, тут можно еще много говорить но думаю мы вернемся к этой теме когда будем рассматривать непосредственно подготовку к установки Active Directory. 

Давайте сделаем некоторый общий алгоритм того что мы должны сделать что бы задать иерархию доменов.

1. Определит количество деревьев в лесу.
2. Назначить каждому дереву свой корневой домен.
3. Расположить оставшиеся дочерние домены на более низких чем корневые домены уровнях иерархии.

Еще нам предстоит дать наименование  нашим доменам.

Процесс именования доменов.

Данный процесс строится по следующему алгоритму.

1. Присваивание имен DNS корневым доменам во всех наших лесов.
2. Присваивание имен DNS корневым доменам всем деревьям нашей фирмы.
3. Присваивание имен DNS всем оставшимся дочерним доменам, в строгой соответствии с их положением в иерархии.

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

Так вот после присваивание имен DNS мы должны так же разобраться с размещением серверов DNS а так же с планированием дополнительных зон DNS  и принять решение о методе репликации этих зон.    

Третий этап. Создание плана подразделений (OU).

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

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

• Делегирование административных полномочий,
• Сокрытие объектов,
• Администрирование групповой политики.

Делегирование полномочий позволяет, с одной стороны, избавиться от присутствия и вмешательство "противных"  администраторов, а с другой — уменьшить их объем работы, передав отдельные административные функции в подразделения.

Сокрытие объектов применяется при необходимости  скрыть некоторые объекты в сети от некоторых пользователей. для этого можно отдельное подразделение и ограничить круг лиц с правом List Contents для этого OU. 

Под администрированием групповой политики надо понимать применения групповых политик на данное OU. Если вы не собираетесь применять различные групповые политики к отдельным OU  то надобность в таких подразделениях, в данном случае отпадает.

Четвертый этап. Создание топологического плана сайтов.

Мы  уже коснулись этой темы когда определяли количество доменов. Остановимся еще немного на этом.

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

Отдельный сайт нужно создать для следующих объектов:

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

В принципе после анализа нашего составленного на бумаге плана, выявление отдельных областей, то есть сайтов мы поставили по одному контроллеру домена в сайтах. Хотя в том алгоритме говорится о том что количество контроллеров вы принимайте исходя из требования того что контроллер домена всегда доступен, и время его реагирования на наши запросы быстрое. Это мы определяем проследив путь регистрации пользователей, трафика репликации, размещение GC и общий анализ загрузки сети. На основе этой информации мы принимаем решение о количестве контроллеров домена. 

Тем не менее что бы добиться оптимальных показателей быстродействия нашей сети и готовность приложений, по правилам нужно разместить по меньшей мере:

• По одному контроллеру домена на каждом сайте,
• По два контроллера доменов в каждом домене.

То есть как мы видим из этих требований могут быть сайты без контроллеров домена, но это не желательно так как одна их причин разделения на сайты и есть скорость обмена между ними. И тогда подумайте о тех пользователей которые окажутся в сайтах которые по той или иной причине не имеет свой контроллер домена.

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

• канал связи медленный, 
• канал ненадежный, 
• канал перегружен.  

Тут же на этом этапе определяемся с стратегией репликации. Правильный выбор стратегии репликации повышает отказоустойчивость и эффективность репликации. Тут нам предстоит как сетевым администраторам создать конфигурацию межсайтовых ссылок, назначить транспорт репликации, установит частоту репликации и готовность репликации. Кроме того мы можем указать предпочтительные серверы-плацдармы (bridgeheat servers) между сайтами. 

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

Не пугайтесь все это мы пройдем и будем делать непосредственно ручками в Active Directory. Но главное не в умение ставить фишки в настройке, а понимать что ты делаешь, поэтому сперва столько теории.