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

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

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

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

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

Что делает систему хорошей? Давайте посмотрим:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

После того как мы выявили структуру своей организации и границы безопасности, следующим моментом является указание имеющейся структуры физической вычислительной сетевой среды. Важно указать сколько имеется сетевых сред филиалов, как они связываются воедино, а также какие виды полос пропускания доступны между площадками. Эти сведения помогут нам спроектировать структуру данного домена. Кроме того, как часть данного упражнения, важно указать потенциальные проблемы и узкие места между физически обособленными сетевыми средами. В сетевых схемах соединения связи между площадками могут выглядеть чудесно, однако если эти соединения имеют проблемы с надёжностью и полосой пропускания, они также должны быть отражены в вашем проекте. Для осуществления этого получите отчёты об использовании и доступности за последние три месяца и просмотрите их. Это снабдит вас отличным пониманием внутреннего строения. В Главе 1, Основы 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. желает изолировать службы в Resource forest, поскольку она готовится к слиянию с другой компанией предоставления услуг ИТ в последующие шесть месяцев. После того как слияние будет завершено, другая компания сможет использовать данный Лес ресурсов также для доступа к этим службам и ресурсам. Это только потребует установления доверительных отношений между Лесом этой компании и Resource forest.

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

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

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

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

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

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

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

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

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

Данная модель сложнее чем модель с единственным доменом и будет требовать дополнительного оборудования и ресурсов. В этой модели данные раздела домена будут реплицироваться в контроллеры домена внутри такого домена и это позволит вам снизить поток обмена репликациями в WAN подключениях. Эта модель также поможет вам с изоляцией требований безопасности. Обратите внимание, что она не предоставляет изолированности данных или служб. Если они необходимы, их следует выполнять на уровне соответствующего Леса.

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

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

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

Полоса пропускания	Когда для репликаций допускается 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не рекомендуется чтобы вы использовали исключительно виртуальные контроллеры домена. На практике для доступности и целостности рекомендуется некий баланс между физическими и виртуальными контроллерами домена. Это в особенности применимо когда виртуальные контроллеры домена и кластеры Hyper-V используются в том же самом домене. Например, Rebeladmin Corp. использует в качестве своего первичного домена rebeladmin.com. Когда компания начинала, для размещения ролей своего сервера применялись физические серверы. Компания работала с двумя физическими контроллерами домена Active Directory. Со временем, в эпоху виртуализации, компания создала некий кластер Hyper-V. Этот кластер также вошёл в состав общего домена rebeladmin.com. Наша компания перенесла рабочие нагрузки с физических серверов в серверы виртуальные. По мере выхода новых выпусков Active Directory, они настраивали новые виртуальные контроллеры домена и перемещали роли FSMO в виртуальные контроллеры домена. Служба кластера Hyper-V требует сопровождения 50% и более доступности хостов для поддержки кворума. В случае отказа оборудования, когда данная система утрачивает кворум, такой кластер останавливается и рабочие нагрузки не выполняют миграцию подобающим образом. Так как при данном событии все имеющиеся контроллеры виртуальные, в момент загрузки Hyper-V существуют проблемы с аутентификацией кластера, поскольку виртуальные контроллеры домена остановлены. Таким образом, убедитесь что на данный случай вы используете физические контроллеры домена.

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

Таблица 3-2. Да и нет виртуальных контроллеров домена

Да	Нет
Запуск контроллеров домена в различных виртуальных кластерах различных ЦОД во избежание единственной точки отказа	Не сохраняйте базу данных Active Directory и файлы журнала в виртуальных IDE дисках. Для надёжности храните их в VHD, которые подключены к некому виртуальному контроллеру SCSI.
Важна безопасность VHD (Virtual hard disk), так как копию VHD можно поставить в соответствие некому компьютеру и считать его данные. Если некто без полномочий получит доступ к ntds.dit, это раскрывает имеющуюся идентичность. Hyper-V предоставляет свойства экранированных (shielded) ВМ для шифрования необходимых VHD и предотвращения не авторизованного доступа.	В некой виртуальной среде инженеры применяют для более быстрого развёртывания операционных систем шаблоны. Не устанавливайте свой контроллер домена в некую операционную систему, которая не подготавливалась при помощи sysprep.
Отключите синхронизацию времени между своим виртуальным контроллером домена и его хостом. Это сделает возможной синхронизацию времени контроллера домена с PDC.	Для создания дополнительных контроллеров домена не применяйте копию уже развёрнутого контроллера домена.
N/A	Не пользуйтесь функциональностью экспорта Hyper-V при экспорте своего виртуального контроллера домена (для целей откатов и восстановления).
N/A	Не ставьте на паузу и не останавливайте контроллеры домена на длительный промежуток времени (дольше значения времени жизни столбового камня - tombstone).
N/A	Не делайте моментальные снимки виртуальных контроллеров домена.
N/A	Не применяйте диски VHD с дифференциальными приращениями, так как они снижают общую производительность.
N/A	Не копируйте и не клонируйте 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 серии, автомат, 2018 года, очень просто найти то, что мне нужно. По мере того как мы верно выражаем свои требования, а также вместе с тем поставщики их правильно улавливают, мы получим именно то решение, которое мы ищем.

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

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

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

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

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

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

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

В этом разделе мы рассмотрели те моменты, которые нам необходимо рассматривать при проектировании некой Гибридной идентификации. В Главе 15, Наилучшие практические приёмы Active Directory и Главе 17, Гибридная установка Azure Active Directory я продемонстрирую как реализовывать необходимые службы/ функциональные возможности, которые мы здесь обсуждали.

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

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

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