Глава 3. Проектирование инфраструктуры Active Directory

Разведение рыбок это интересное хобби, и в детстве оно мне очень нравилось. Мне пришлось выявить проблемы с некоторыми аквариумами для разных видов рыбок. Мы с отцом делали аквариумы дома. Прежде чем создать некий аквариум, мы сначала решаем какой размер аквариума нам требуется. Тип и толщина стекла зависели от ёмкости резервуара. Затем нам был необходим подходящий клей для сборки аквариума.

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

при проектировании какой бы то ни было системы, это во многом похоже на герметичность аквариума для рыбок или лодки. Мы можем не достичь успеха с первой попытки. Нам необходимо предусмотреть место для ошибок. Возможно, нам придётся повторять ту же самую задачу несколько раз, прежде чем выполнить полную гидроизоляцию резервуара или лодки. По завершению процесса гидроизоляции нам надлежит поддерживать её в рабочем состоянии. Может так случиться, что со временем клей начнёт отслаиваться и протечки могут появиться снова.

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

Из приведённого выше примера мы можем вынести несколько уроков:

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

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

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

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

При проектировании некой инфраструктуры Active Directory с нуля, было бы идеально, если бы управляющие смогли подтвердить чем она станет через 10- 20 лет. Тогда вы знали бы что делать. Но это происходит в неком идеальном мире. Когда случаются организационные изменения, они способны также оказывать воздействие и на имеющуюся инфраструктуру. Это могут быть такие изменения, как введение некого нового подразделения, набор бо́льшего числа персонала, работа с вновь приобретёнными компаниями или выполнение слияния компаний. Некоторые из таких изменений могут реализовываться просто, а некоторые могут потребовать больших изменений во всей организации. Такие изменения могут варьироваться от создания нового Подразделения организации (OU) до введения нового леса Active Directory.

Например, когда Rebeladmin Corp. сливается с My-Learning Inc. Управлению Rebeladmin Corp. необходимо выполнить централизацию администрирования ИТ и совместно применять ресурсы двумя организациями. Обе организации поддерживают свои собственные леса Active Directory. Лес My-Learning Inc. пребывает вне границ безопасности инфраструктуры идентификации Rebeladmin Corp. Для их слияния нам требуется создать некое взаимоотношение доверия леса или доверия домена между данными двумя установками Active Directory. С такими изменениями инфраструктура идентификации Rebeladmin Corp. получит новые границы безопасности, а также новые активы для управления.

Исправление унаследованных ошибок проектирования имеет высокую стоимость для организаций. В большинстве случаев они завершаются перестроением инфраструктур домена. Не так давно я имел переговоры с некой компанией относительно перестроения домена. Это торговая компания с многомиллионным оборотом в долларовом выражении и с офисами по всему миру. Основная проблема состояла в том, что когда они спроектировали давным давно свою инфраструктуру AD, они воспользовались для своего первичного домена именем SLD (single label domain, доменом с единственным именем поля).

SLD являются доменными именами, которые не имеют суффиксов DNS, таких как .com, .org или .net. По прошествии некого времени они осознали те ограничения, которыми обладают SLD, однако не исправили этого как требовалось через некие административные изменения. Никто не хотел брать на себя ответственность. Их компания продолжала расти, а вместо того чтобы исправлять имеющуюся фундаментальную проблему, они продолжали вводить новые леса и новые домены.

В конце концов, всё это стало практически неуправляемым, причём со множеством доменов и лесов, которые не имели смысла. По этой причине у них не оставалось никакого иного выбора помимо перестроения всей структуры Active Directory целиком, так как их организация приняла решение переноса основных рабочих нагрузок в Azure Cloud. Однако это было очень дорогостоящим и болезненным изменением. Когда у вас имеется возможность срезать растущие у вас в саду сорняки собственными руками, делайте это прямо сейчас; не ждите пока вам потребуется пила.

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

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

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

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

Когда вы получаете требования компании, вам требуется рассматривать следующее:

Для поиска относящихся к делу сведений вы можете применять подобные приводимым ниже вопросы:

Все предыдущие вопросы помогут вам собрать сведения о компании, которые важны для проектирования Active Directory. Помимо приведённых выше, вам может потребоваться добавить дополнительные вопросы на основе отрасли действия, размера компании, согласованности и тому подобного.

Наш следующий этап в обсуждаемом процессе состоит в определении границ безопасности. Когда вы покупаете пустой участок земли для постройки дома, что будет самым первым что вам предстоит сделать? Вам необходимо указать установленные границы делянки. Ваши здания/ развёртывания не могут выходить за них. Какой вид сведений вам необходимо получать чтобы определять границы инфраструктуры идентификации? Для этого жизненно важно понимать операции бизнеса.

Rebeladmin Corp. владеет некой группой компаний. Действия каждой из компаний совершенно отличаются друг от друга. Одна из них является компанией хостинга, а другая является институтом обучения ИТ. Они также имеют некую фармацевтическую компанию. Операционные требования и бизнес- требования отличаются для каждой из этих компаний. В данной ситуации идеальным будет множество лесов, поскольку ни одна из команд в своих действиях не зависит от ресурсов прочих.

Порой, даже когда это некая отдельная компания, некие подразделения бизнеса могут нуждаться в логическом обособлении - по крайней мере с точки зрения самой службы каталога. Например, Rebeladmin Corp. имеет подразделение исследований и разработки. Инженеры этого подразделения продолжают тестировать новые программное обеспечение и службы, причём большинство из них интегрированы с Active Directory. К тому же их требования безопасности быстро меняются. Им требуется проверять различные Групповые политики для целей тестирования. Когда это один и тот же лес Active Directory, имеющиеся действия этих тестов будут воздействовать на весь имеющийся каталог. Следовательно, наилучшим вариантом была бы изоляция их действий в неком отдельном лесу.

После того как мы выявили структуру своей организации и границы безопасности, следующим моментом является указание имеющейся структуры физической вычислительной сетевой среды. Важно указать сколько имеется сетевых сред филиалов, как они связываются воедино, а также какие виды полос пропускания доступны между площадками. Эти сведения помогут нам спроектировать структуру данного домена. Кроме того, в качестве части данного упражнения, важно указать потенциальные проблемы и узкие места между физически обособленными сетевыми средами. В сетевых схемах соединения связи между площадками могут выглядеть чудесно, однако если эти соединения имеют проблемы с надёжностью и полосой пропускания, они также должны быть отражены в вашем проекте. Для осуществления этого получите отчёты об использовании и доступности за последние три месяца и просмотрите их. Это снабдит вас отличным пониманием внутреннего строения. RODC (read-only domain controllers, Доступные только на чтение контроллеры домена) применяются в сетевых средах филиалов, когда те не способны гарантировать безопасное и надёжное соединение. Даже когда имеющиеся офисы филиалов соединены воедино, а связи не являются надёжными, и когда эти связи уже были полностью задействованы, нам требуется вначале исправить такие узкие места и поместить RODC вместо полнофункционального Контроллера домена. В этом вам поможет сбор свидетельств.

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

Для проектирования инфраструктуры идентификации также важна модель ИТ администрирования рассматриваемой компании. Она может быть централизованной или децентрализованной. Rebeladmin Corp. обладает группой компаний. Каждая из этих компаний имеет своё собственное подразделение ИТ. Поэтому каждая команда ИТ подразделения отвечает за свою собственную инфраструктуру. В такой ситуации, сопровождение обособленных лесов поможет разделять ответственности для операций ИТ. Кроме того, некоторые компании могут передавать свои операции ИТ на обработку сторонним компаниям. Это изменит установленные требования безопасности в установленной инфраструктуре идентификации с внутренних ИТ операций. Некоторые из имеющихся рабочих нагрузок могут потребовать их изоляции по причине защиты данных и юридических требований. Разрабатываемое построение потребует соответствия этих типов требованиям операций ИТ.

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

Требования современной инфраструктуры идентификации усложняются. Некоторые организации уже расширили свои инфраструктуры инициализации на облачные решения. Часть организаций целиком перешла в управляемые Azure Active Directory домены. Большинство производителей приложений переместили свои продукты в имеющиеся общедоступные облака. Компаниям требуется совместно сотрудничать с происходящими вокруг них изменениями. Некоторые продукты и службы больше не будут работать в качестве внутренних служб, а клиентам придётся перейти к соответствующим облачным версиям. Устанавливаемая архитектура инфраструктуры идентификации должна быть в максимальной степени ориентирована на будущее. Таким образом, важно проводить исследования и оценивать новые технологии и службы, которые способны улучшать имеющуюся инфраструктуру идентификации организации и приспосабливать её построение по мере необходимости.

В любом проекте собственно этап реализации относительно прост. Процесс же проектирования и планирования является сложным и требует много времени, но он жизненно важен для удовлетворения бизнеса. После того как вы собрали сведения в соответствии с описанием, пройдитесь по ним несколько раз и окончательно уясните их. Если у вас остались сомнения, идите и собирайте дополнительные сведения для их прояснения. Когда Джонатан Айв проектировал свой Apple Mac, неужели вы верите в то, что он спроектировал его за раз? Я уверен что он применял шредер. Однако, в результате, все любят дизайн Apple. Никто не плачет о том как же ему было тяжело и как много времени это потребовало. Конечным результатом оказался безграничный успех. Итак, не бойтесь применять шредер на этапе проектирования.

Проектирование Active Directory начинается с проектирования основной структуры Леса (forest). Лес Active Directory выступает границами безопасности для создаваемой инфраструктуры идентификации. Когда вы развёртываете свой самый первый контроллер домена в вашей инфраструктуре, он создаёт также и некий Лес. Всякая инфраструктура Active Directory обладает по крайней мере одним Лесом.

Существует две разновидности реализации Леса:

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

Развёртывание с отдельным Лесом выступает установленным по умолчанию режимом. Большинство моделей ведения дел укладываются в модель с отдельным Лесом. Для этой модели сложность и стоимость реализации минимальны. Один из основных моментов, который вам требуется рассматривать для данного режима, это репликации. Домены используются для деления на разделы основного каталога и управления необходимыми репликациями. Однако данные для всего Леса, такие как схемы, всё ещё требуется реплицировать между всеми доменами. Когда в репликации вовлечены офисы филиалов, вам требуется гарантировать надлежащую обработку репликаций по всему Лесу. Мы всегда можем начать сперва с модели отдельного Леса, а затем позднее, в случае необходимости, перейти ко модели множества Лесов.

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

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

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

Существует два вида автономии:

В большинстве ситуаций организации выбирают вариант с изоляцией вместо автономности. Давайте двинемся дальше и рассмотрим что может дать изоляция.

Изоляция

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

Существует два вида изоляции:

Общее число требуемых для некой инфраструктуры Лесов зависит от требований автономности и изолированности.

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

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

Когда принято решение по необходимой модели Леса и общем числе Лесов, нашим следующим шагом является выбор моделей проектирования Леса. Существует три модели проектирования Леса: организации, ресурсов и ограничений.

При модели Леса, соответствующей организации, ресурсы, данные и идентификация будут оставаться в отдельных лесах и будут продолжать управляться независимо. Эту модель можно применять для предоставления автономности служб, изоляции служб или изоляции данных:

В нашем предыдущем примере, Rebeladmin Corp. и My training являются двумя компаниями под одной и той же материнской компанией. Согласно операционным требованиям им необходима изоляция служб. Для её осуществления инженеры создали два отдельных Леса. Каждая из компаний обладает своим собственным подразделением ИТ и независимо управляет идентичностями. Если ресурсам требуется совместное использование между двумя Лесами, это может быть выполнено через доверительные отношения между Лесами.

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

Леса ресурсов действительно полезны при вашей работе со множеством лесов организаций, располагающихся во множестве стран. Это поможет выполнить изоляцию на основе юридических, нормативных требований и требований производительности. Как пример, Rebeladmin Corp. обладает филиалами в США, Европе и Азии. Каждый регион имеет множество филиалов и некоторые из таких филиалов расположены в различных странах. Давайте оценим некоторые из возможных архитектур, к которым мы можем прийти, а также все связанные с этим за и против.

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

Таблица 3-1. За и против Примера 1

За	Против
Индивидуальные площадки всё ещё будут обладать наивысшим уровнем контроля над своими собственными данными и доступом.	По мере роста числа площадок возрастает значение числа делегирований, что подразумевает и рост управления
Больший нормативный контроль	Проблемы с сопровождением стандартов безопасности по причине обширных границ администрирования (для региональных областей).
Ме́ньшая зависимость от соединений между площадками.
Более простая реализация SSO при помощи применения Лесов ресурсов.
Более простое применение глобальных стандартов безопасности.
Индивидуальные площадки всё ещё обладают автономностью данных и служб.
Более простое сопровождение служб и общих данных через Леса ресурсов.
Ме́ньшее воздействие на общие службы и данные по причине изменений инфраструктуры на уровне площадки.
Бо́льший контроль над делегированием привилегий.

В приведённой выше архитектуре я в основном сосредоточился на двух моментах. Один это требования нормативного сопровождение, которые применяются на уровне регионов. Другой это улучшение производительности путём поддержки Лесов региональных ресурсов. Порой существуют юридические требования для хранения данных или использования служб в любом случае в том же самом регионе. В приводимом выше примере домены Великобритании и Германии соединены с Лесом ресурсов в регионе Европы. Следовательно, владелец этого Леса может помещать приложения и службы, которые относятся к данному региону, в данном Лесе ресурсов. К тому же, таким образом, области Европы не будут обладать зависимостями от соединений между регионами для доступа к своему Лесу ресурсов. В прведённом выше примере я также упомянул один Лес глобальных ресурсов. Именно он будет применяться для совместного использования приложений и служб по всему бизнесу. Кроме того, при таком подходе каждые страна или филиал смогут обладать своим собственным Лесом организации. Это придаст бо́льшую гибкость управлению.

Таблица 3-2. За и против Примера 2

За	Против
Больше вариантов для размещения данных и служб.	Больше доменов, больше управления, больше сложность.
Больше нормативного контроля.	Зависимость от доверительных отношений доменов и соединений между доменами и Лесами.
Ме́ньшая зависимость от соединений между регионами.	Требуется более сложное и более тщательное планирование при внесении на борт новых организаций.
Больше контроля над стандартами безопасности (можно применять стандарты на различных уровнях).
Ме́ньшее воздействие на службы при региональных простоях.

Модель Леса ограничения доступа

При модели Леса, соответствующей ограничению доступа, для изоляции идентичностей создаётся некий отдельный Лес, а данные должны быть обособлены от прочих данных идентичностей организации. Между такими двумя Лесами не создаётся доверия, поэтому идентичности из одного Леса не будут иметь возможности доступа к ресурсам в другом. Для доступа к ресурсам в каждом из Лесов нам требуется иметь отдельные учётные записи пользователей. Данная модель Леса ограничения доступа предоставляет изоляцию данных:

В нашем предыдущем примере Rebeladmin Corp. вовлечена в некий процесс лишения прав корпорации. Для неких активов здесь требуется полная изоляция данных и идентичностей. Для осуществления этого компания вводит Лес ограничения доступа. Обычно данная модель применяется по причине юридических/ нормативных требований, требований безопасности или требований операций ИТ.

Раз необходимая структура Леса, общее число Лесов и их модели проектирования были завершены, нашим следующим этапом будет проектирование необходимой структуры доменов.

Всякий AD DS Лес имеет по крайней мере одним доменом. Когда вы устанавливаете свой первый Лес доменов, это также установит и некий домен по умолчанию. Имеется несколько причин почему вам может потребоваться рассмотреть возможность множества доменов в одном лесу:

Существуют две модели, которые мы можем применять при проектировании такой структуры домена: модель с отдельным доменом и модель региональных доменов

Модель с единственным доменом содержит структуру единственного- домена единственного- леса. Она проще для администрирования и имеет меньшую стоимость реализации. Когда мы впервые настраиваем инфраструктуру Active Directory, это будет именно данная модель по умолчанию. Этот домен становится доменом корня в данной модели по умолчанию с единственным доменом. Наш домен станет по умолчанию корневым доменом для своего леса и в нём будут храниться все объекты:

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

В модели регионального домена Лес AD DS содержит корневой домен Леса и множество доменов, которые подключаются через WAN (wide area networks). В основном это приемлемо для офисов филиалов и подчинённых компаний, которые расположены в различных географических местоположениях:

Данная модель сложнее чем модель с единственным доменом и будет требовать дополнительного оборудования и ресурсов. В этой модели данные раздела домена будут реплицироваться в контроллеры домена внутри такого домена и это позволит вам снизить поток обмена репликациями в WAN подключениях. Вы можете найти дополнительные сведения относительно репликации AD в Главе 11, Службы Active Directory - Часть 01. Модель регионального домена также поможет вам с изоляцией необходимых требований безопасности. Обратите внимание, что она не предоставляет изолированности данных или служб. Если они необходимы, их следует выполнять на уровне соответствующего Леса.

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

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

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

Таблица 3-3. Зависимость числа пользователей от значения полосы пропускания

Полоса пропускания	Когда для репликаций допускается 1% полосы пропускания	Когда для репликаций допускается 10% полосы пропускания
128 kbps	25 000	100 000
256 kbps	50 000	100 000
512 kbps	80 000	100 000
1.5 Mbps	100 000	100 000

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

По мере роста числа доменов, также растут сложность, стоимость реализации и сопровождения, а также управление разнообразием сетевых настроек. Таким образом, принимайте решение по числу доменов разумным образом. Я часто встречаю людей, создавших домены в тех местах, где они могли достичь тех же самых моментов при помощи OU или неких иных Групповых политик.

Каждый домен в общем лесу обладает неким уникальным именем. Существует два вида имён: имена NetBIOS применяются для основанных на SMB- совместных ресурсов и обмена сообщениями Windows, в то время как имена DNS могут разрешаться в интернете и различных системах. Когда вы активируете свой домен, он запрашивает значения для имени DNS, а также названия NetBIOS.

При выборе названия держите в уме следующие моменты:

В качестве рекомендации, когда ваша организация обладает неким доменным именем компании, попробуйте применить его также и в качестве названия домена Active Directory. Это к тому же упрощает интеграцию с Azure AD. При планировании имён для дочерних доменов, вы можете пользоваться названиями стран, континентов или филиалов. В качестве примера, Rebeladmin Inc. обладает филиалом в Великобритании, поэтому значением дочернего домена для него может быть UK.rebeladmin.com или Europe.rebeladmin.com. Такое имя домена должно быть достаточно ясным для пояснения его цели. Например, когда поддомены носят названия branch1.rebeladmin.com, branch2.rebeladmin.com и так далее, эо не даст никому никакой ясности.

После того как доменное имя было присвоено, оно не может быть изменено без повторного развёртывания, выполнения процесса переименования домена или осуществления миграции домена. Однако Active Directory может обладать множеством суффиксов UPN.

Самым первым настраиваемым в вашем Лесу доменом является корневой домен Леса. Такой корневой домен содержит две важные привилегированные группы, которыми выступают Администраторы компании и Администраторы схемы (Enterprise Admins и Schema Admins). Участники этих групп безопасности способны добавлять/ удалять домены и изменять имеющуюся схему Active Directory.

В модели со множеством доменов имеются два типа, которыми вы можете задать необходимый корневой домен Леса:

Теперь у нас имеются все необходимые сведения для проектирования общей структуры доменов. Наш следующий этап будет состоять в определении уровней функциональности домена и Леса.

После того как проект домена и Леса готовы, наш следующий шаг состоит в принятии решения по необходимым уровням функциональности домена и леса. Значение уровня функциональности Леса и домена задаёт функциональные возможности, которые могут применяться в его инфраструктуре идентификации. Вы не можете обладать функциональными возможностями AD DS 2022, когда на уровне функциональности домена и леса в вашей организации запущен Windows Server 2012. Когда вы добавляете соответствующий контроллер домена в уже имеющиеся Лес и домен, он автоматически установит соответствие с имеющимся уровнем функциональности Леса и домена.

Когда вы принимаете решение относительно уровней функциональности своих Леса и домена, вам следует рассмотреть пару моментов:

После того как вы определились с уровнями функциональности устанавливаемых Леса и домена, в вашу систему не могут вводиться контроллеры домена с более низким значением версии. Когда у вас запущены уровни функциональности Леса и домена Windows Server 2016, вы не сможете в том же самом Лесу запустить контроллер домена Windows Server 2012R2.

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

В Active Directory существуют различные типы объектов, такие как учётные записи пользователей, группы и устройства. Важно действенно управлять ими. OU способны группировать объекты, которые обладают аналогичными административными требованиями и требованиями безопасности внутри общего домена. Организационные элементы (OU) применяются для делегирования необходимого администрирования объектам и применения Групповых политик.

Изменения строения OU менее сложны по сравнению с изменениями структуры уровней домена и Леса. При перемещении вами объектов из одного OU в другой, они будут наследовать те настройки безопасности и Групповые политики, которые применяются к OU назначения. Это перемещение не берёт с собой никакие настройки, которые имелись на уровне исходного OU.

Администраторы домена способны делегировать полномочия пользователям чтобы назначать их Администраторами OU. Администраторы OU способны управлять объектами и политиками в рамках выбранного OU. Они способны создавать дочерние OU и делегировать полномочия другому пользователю/ другим пользователям для управления дочерним объектам OU. Администраторы OU не имеют возможности контролировать действия служб своего каталога и именно это является иным способом управления привилегированным доступом в рамках имеющегося каталога. Это достаточно похоже на тот способ, которым работают полномочия NTFS.

Существует два типа организационных элементов:

При определении вами необходимого дерева OU важно следовать неким стандартам. Эти стандарты могут быть особенными для требований вашей организацию В приводимом ниже списке я упоминаю несколько методов, которые могут применяться для организации некого дерева OU:

Допускается также и смешение всех этих методов. Нет никаких ограничений на общее число дочерних OU, которые вы можете создавать, однако исходя из целей администрирования и управляемости Microsoft рекомендует вам не иметь более 10 уровней.

После того как вы завершили свою структуру OU, убедитесь что задокументировали её подобающим образом. Кроме того, предоставьте руководства с тем, чтобы инженеры могли следовать применяемому вами методу. Когда я работал над проектами, я обратил внимание, что некоторые структуры OU вовсе не имеют никакого смысла, поскольку с течением времени разные инженеры применяли свои собственные методы структурирования OU. Организации должны иметь некий стандарт для подражания.

Таблица 3-4. Что следует делать, а что нет

Следует	Не следует
Запускать Контроллеры домена в различных виртуальных кластерах из различных Центров обработки данных (ЦОД) во избежание единой точки отказа	Не сохранять базу данных и файлы журналов Active Directory в виртуальных дисках IDE
Безопасность Virtual hard disks (VHD) важна, поскольку скопированные VHD можно ставить в соответствие некому компьютеру и считывать данные внутри него. Если некто получит доступ к ntds.dit, это вскроет идентификационные данные. На стороне сервера мы можем применять службы шифрования для шифрования дисков с управляемыми клиентом ключами.
Отключите синхронизацию времени между соответствующим виртуальным Контроллером домена и его хостом. Это позволит Контроллерам домена выполнять синхронизацию времени с PDC.	Не применяйте копию уже развёрнутого VHD Контроллера домена при создании дополнительных Контроллеров домена.
	Не применяйте функциональную возможность экспорта Hyper-V для экспорта имеющегося виртуального Контроллеров домена (для целей отката или восстановления).
	Не ставьте на паузу и не останавливайте Контроллеры домена на длительное время (дольше чем время жизни надгробия {tombstone lifetime - времени жизни одного из контейнеров AD, содержащего удалённые из AD объекты, как правило, 60 дней}).
	Не выполняете моментальных снимков виртуальных Контроллеров домена.
	Не пользуйтесь дисками приращений VHD, поскольку это снижает производительность.
	Не копируйте и не клонируйте VHD Active Directory.

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

Большинство имеющихся в современных инфраструктурах рабочих нагрузок виртуальные. Контроллеры домена также могут быть виртуальными; однако, в зависимости от поставщика виртуализации рекомендуемые способы также могут отличаться. Тем самым, когда вы планируете развёртывать виртуальные контроллеры домена, обратитесь за справочными сведениями к своему производителю программного обеспечения и найдите те рекомендации, которые он даёт для виртуальных контроллеров домена. Приводимые нами в данном разделе рекомендации сосредоточены вокруг платформы виртуализации Microsoft Hyper-V.

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

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

В приводимой ниже таблице я перечислил что стоит, а что не следует делать в отношении виртуальных Контроллеров домена:

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

Таблица 3-5. Что следует и что не стоит предпринимать в виртуальных контроллерах домена

Следует	Не следует
Запуск контроллеров домена в различных виртуальных кластерах различных ЦОД во избежание единственной точки отказа	Не сохраняйте базу данных Active Directory и файлы журнала в виртуальных IDE дисках. Для надёжности храните их в VHD, которые подключены к некому виртуальному контроллеру SCSI.
Важна безопасность VHD (Virtual hard disk), так как копию VHD можно поставить в соответствие некому компьютеру и считать его данные. Если некто без полномочий получит доступ к ntds.dit, это раскрывает имеющуюся идентичность. На стороне сервера мы можем применять службы шифрования для шифрования дисков с управляемыми клиентом ключами.
Отключите синхронизацию времени между своим виртуальным контроллером домена и его хостом. Это сделает возможной синхронизацию времени контроллера домена с PDC.	Для создания дополнительных контроллеров домена не применяйте копию уже развёрнутого контроллера домена.
	Не пользуйтесь функциональностью экспорта Hyper-V при экспорте своего виртуального контроллера домена (для целей откатов и восстановления).
	Не ставьте на паузу и не останавливайте контроллеры домена на длительный промежуток времени (дольше значения времени жизни надгробия {tombstone lifetime - времени жизни одного из контейнеров AD, содержащего удалённые из AD объекты, как правило, 60 дней}).
	Не делайте моментальные снимки виртуальных контроллеров домена.
	Не применяйте диски VHD с дифференциальными приращениями, так как они снижают общую производительность.
	Не копируйте и не клонируйте VHD Active Directory.

Местоположение контроллера домена в имеющейся инфраструктуре зависит от ряда моментов:

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

В некой среде единственного- леса единственного- домена все контроллеры домена могут быть серверами Глобального каталога, поскольку он не будет отличаться от репликаций домена. Однако в среде со множеством доменов размещение сервера Глобального каталога включает в себя и планирование, поскольку он увеличивает объём подлежащих репликации данных, а также используемую полосу пропускания.

При размещении сервера Глобального каталога следует принимать во внимание определённые моменты:

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

Имеется множество причин, по которым организации рассматривают возможность расширения их локального AD в AD Azure. Давайте рассмотрим некоторые из таких причин:

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

По этой причине им приходится принимать решения по расширению локального AD в Active Directory Azure. Наше окончательное решение содержит выполнение следующего:

Наш предыдущий сценарий является исключительным примером для настройки Гибридной идентификации. помещаемое на место решение не только расширяет инфраструктуру идентификации, но и использует связанные с Azure AD службы и функции для улучшения управления идентификацией и доступом, защиты идентификационных данных и безопасности данных по всем направлениям. Однако у каждой организации свой бюджет, свои бизнес- требования и разные навыки, и всё это повлияет на проект Гибридной идентификации. Давайте рассмотрим несколько областей, которые принимать к сведению при разработке Гибридной идентификации.

Давайте рассмотрим несколько областей которые вам надлежит принимать во внимание при разработке вашей гибридной идентификации.

Компании перемещаются в облачные решения по многим причинам. Основываясь на наших намерениях, мы можем сгруппировать эти организации по четырём категориям:

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

Когда я захожу на вебсайт Auto Trader просто для поиска машины, я получаю более 400 000 результатов. Просто невозможно пройти по ним всем для поиска той машины, что сидит в моём сознании. Однако если я, допустим, сообщу что мне нужна BMW 4 серии, автомат, сборки 2020 года, очень просто найти то, что мне нужно. По мере того как мы верно выражаем свои требования, а также вместе с тем поставщики их правильно улавливают, мы получим именно то решение, которое мы ищем.

Бизнес- потребности имеют различные формы. Это может быть вид прибыли, улучшения операций, изменения стратегии или требования соответствия/ безопасности. Для предоставления надлежащего решения нам требуется знать все входящие и исходящие требования. Это наиболее вызывающая стадия процесса проектирования для инженеров. Она всегда запускает некий сорт взаимодействия между инженерами и владельцем бизнеса, директором, управляющим или главой подразделения. Некоторые из них не будут обладать достаточными техническими сведениями чтобы пояснить в точности то что им требуется от Гибридной идентификации. Следовательно, будет лучше применять общие вопросы для получения по возможности дополнительных сведений.

Для проектирования Гибридной идентификации нам требуется получить сведения для следующих областей:

В своих приводимых далее подразделах я перечислил набор общих вопросов и того что мы можем предоставлять на выходе:

Помимо приведённых выше технических оценок, мы также можем рассмотреть потребности компании, которые могут оказывать воздействие на рассматриваемую архитектуру:

Синхронизация контролирует как ваши идентичности появляются в соответствующем облачном решении. В обычной среде AD инженеров осуществляют связанные с идентичностью изменения, такие как смену пароля, замена имени, изменение членства в группах, а также добавление/ изменение персональных атрибутов. Для некой Гибридной системы идентичность в применяемом облачном решении должна представлять те же самые характеристики что и локальная идентичность. Именно по этой причине критически важна синхронизация. Azure AD Connect является инструментом Microsoft, который был разработан для синхронизации локальной идентичности с облачным решением.

Azure AD Connect обладает пятью основными функциональными возможностями:

Давайте рассмотрим несколько моментов, которые вам стоит учитывать при решении по синхронизации:

За безопасность общедоступных облачных служб, таких как Azure, отвечает не только CSP, но и сам заказчик. Модель совместной ответственности помогает нам понять, кто и что защищает в облачной среде. Для PaaS и SaaS ответственность за IAM разделяют заказчик и CSP. Для этого требуется план, который включает в себя такие действия, как управление корпоративными удостоверениями, внедрение элементов управления PIM, внедрение аутентификации без пароля, внедрение Defender для Office 365 и т.д. CSP предоставляет различные продукты и услуги для обеспечения безопасности, которые могут помочь повысить безопасность решений PaaS и SaaS. Ответственность за принятие решения о том, какие решения выбрать и в которые следует вкладывать средства, лежит на самом заказчике. Кроме того, если заказчик находится в гибридной среде, он обязан убедиться, что взлом не распространяется на облачные службы. В атаке Solorigate, как только злоумышленники совершили начальное проникновение, они сместились в сторону и получили контроль над серверами ADFS.

Затем они подделали маркеры SAML для аутентификации в облачных службах. В такой ситуации заказчик несёт ответственность за реализацию соответствующего контроля безопасности во внутренней среде для защиты цифровых идентификационных данных.

Этого можно было избежать, применив модель с нулевым доверием, внедрив модель корпоративного доступа для PAM и реализовав рабочие станции с привилегированным доступом (PAW, Privileged Access Workstations). Кроме того, заказчик мог применять для CSP такие службы как Defender for Identity (с поддержкой серверов ADFS) и Defender for Endpoint для выявления потенциальных рисков. Как мы видим, когда дело касается идентичности, обе стороны должны работать бок о бок.

И последнее, но не по важности, стоимость также имеет некое значение при проектировании требующейся Гибридной идентификации. Службы AD DS не доставляют вам дополнительной стоимости, так как они поставляются вместе с операционной системой Windows Server/ Azure AD является некой управляемой службой и стоит дополнительных денег. Существует некая бесплатная версия Azure AD, однако она очень ограничена функциональностью. Таким образом, когда вы предлагаете свой проект, вам требуется также рассматривать и стоимость лицензирования. Большая часть свойств защиты идентичности и защиты данных доступна лишь в Azure AD P1 и P2. Без них мы не сможем в равной степени охранять бриллианты и скрепки. Когда ваша организация желает отказаться от функциональных возможностей по причине их стоимости, убедитесь что они осознают тот ущерб, который им это может нанести. Дополнительные сведения относительно лицензий и функциональных возможностей Azure AD доступны по https://bit.ly/3nYhxtn. Вы также воспользоваться калькулятором стоимости Azure чтобы найти более- менее подходящую стоимость: https://bit.ly/31yZEKh.

В этом разделе мы рассмотрели те моменты, которые нам необходимо рассматривать при проектировании некой Гибридной идентификации. В Главе 16, Рекомендации Active Directory и Главе 18, Гибридная идентификация я продемонстрирую как реализовывать необходимые службы/ функциональные возможности, которые мы здесь обсуждали.

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

Мы также рассмотрели процесс проектирования Гибридной идентификации. Здесь мы изучили почему важна Гибридная идентификация и что требуется учитывать на протяжении этапа проектирования. Мы также изучили как мы можем получать необходимые сведения о бизнесе при помощи опросов.

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